feat(ios): Activity and Team memory screens, with the companion routes they call - #933
Merged
Merged
Conversation
…s they call The phone twins of the desktop's Activity panel and Team map → Memory. From a bot's profile: "Activity" lists what the bot did, newest first by day, each row with the app and action in words, the recorded arguments, and an outcome chip (ran, failed, running, allowed, denied, needs you). "Team memory" lists the bot's section's shared people, places, decisions and terms, answers proposals waiting for a tap (Remember / Skip), removes entries with a swipe, and adds one by hand. Both are content surfaces; the sending policy, app scopes and fallback chain stay on the desktop, where the companion allowlist has always kept execution policy. The sidecar allowlist gains GET /api/bots/:id/activity and GET/POST/ PATCH/DELETE /api/team-memory, pinned in routes.test.ts. Two fixtures captured from a disposable harness pin the wire shapes for both phone suites: bot-activity.json (an empty page — a fixture harness runs no tools) and team-memory.json (one entry of each kind, added by hand). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Merged
3 of 6 tasks
milind-soni
added a commit
that referenced
this pull request
Oct 3, 2026
…es (#2208) * fix(ios): show and steer messages sent mid-turn A message sent to a busy bot from the phone could simply disappear. The harness answers such a send in one of three ways, and all three live only in the POST's 202 body: the line landed, the engine took it INTO the running turn (`steered`), or the harness is holding it off-transcript until the turn settles (`queued`, with a `queueId`). The iOS client threw that body away. A held message therefore left no trace anywhere — the composer cleared and the words reappeared minutes later, or not at all after a restart. Only the Claude driver can steer, so on every other engine the queue is the only path and mid-turn sending looked broken. Read the receipt, and give the phone what the desktop has had: - `SendReceipt` decodes the 202 leniently — an older harness that answers `{ok:true}` is a plain send, not a failure. - `CompanionState.pendingQueued` holds what the harness is holding, keyed by queueId. A drained line names its entry, so the ghost retires when the real bubble lands; a drain that beats its own POST leaves a bounded tombstone so the late receipt cannot resurrect it. Hydrates and page merges reconcile for a window that slept through the drain. - The chat draws held sends as dashed bubbles below the transcript, each with its own cancel (DELETE …/queue/:id, newly allowed through the sidecar for bots and rooms). - The composer says which of the three will happen, and the send key becomes a clock when the message will wait. With something already waiting, the microphone becomes a green inject: the harness keeps its steer queue across an interrupt, so stopping the turn is what makes those words run now. Send stays available throughout. - A line the engine took mid-turn is marked "sent mid-turn", which is why the reply above it can read as if the bot had not seen it. Inject is bot-only: the phone has no way to interrupt a room, and adding one is a wider change than this bug. Rooms still get the ghost and cancel. The steer e2e test now asserts the two fields a client needs from a queued receipt, and that the drained line carries the same queueId. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(ios): do not fake a cancel a computer cannot perform The sidecar answers 404 "no route: DELETE …" for a route it does not allow, and the harness answers 404 "no such queued message" when the entry is already gone. Treating those alike took the held message off the phone while the computer still intended to run it — and it then arrived anyway, which is worse than the vanishing this branch set out to fix. Any computer whose sidecar predates the queue-cancel allowlist hits this, including the currently released one. Match the harness's own wording positively, so an unfamiliar 404 fails safe: the ghost stays and the person is told the computer needs updating, rather than being shown a cancel that did not happen. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat: say Steer in words, above the chat bar The mid-turn controls were glyphs: a clock on the send key, a green arrow in the composer. Omkar read them on a real phone and said "don't add the clock or the lightning, I don't understand" — and the held message itself, drawn as a dashed outline, he could not see at all on a dark transcript. So the queued message moves out of the transcript and sits directly above the chat bar, where a thing you have not said yet belongs: the text, a labelled `↳ Steer` button, and a bin. Steer stops the turn so those words run now — the harness deliberately keeps its queue across an interrupt, which is what makes stopping a send. The send key goes back to being one arrow with one meaning; what will happen to the message is said in the placeholder instead ("Sends into this turn" / "Sends after this turn"). Both platforms, because the desktop had the same puzzle: its green "inject now" arrow is gone and its queued rows gain the same Steer button. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix: say Steering while the interrupt is still landing Tapping Steer did nothing visible. Measured against a live codex turn, an interrupt takes about 6.3 seconds to actually stop the stream — and for those six seconds the button looked untouched while the bot kept talking, which is indistinguishable from a broken button. Omkar read it as "it did not steer at all", and he was right to. The button now goes to "Steering…" and disables the moment it is pressed, on both platforms. It clears when the queue drains OR when the turn ends — both, so an interrupt that fails to stop the turn cannot leave the row spinning for ever either. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(ios): retire the queued row, and stop streaming a dead turn Two faults, seen together on a phone: a codex turn died mid-essay, and from then on the chat streamed that half-written essay for ever while the Steer button span for ever beside it. The queued row was mine. A `bot` frame carrying a whole transcript replaces `messages[…]` outright instead of appending, so it never runs the retirement that `append` does — the held message stayed above the chat bar long after its line had landed. The desktop has guarded this since the feature shipped (reconcileSnapshotQueues on bot add/patch/task switch); the port covered hydrate and page-merge and missed this path. The stream was older. The live bubble was drawn whenever the buffer held text, gated on nothing, and nothing cleared the buffer when a turn ended without a settled reply — an engine that dies mid-sentence reports the failure as activity, not as text. So the buffer kept its last tokens and the bubble streamed them for ever. Now an idle bot clears the buffer, and the bubble is gated on `busy` as well, so neither alone can strand it. Also a floor under the spinner: it clears after twenty seconds even if neither the drain nor the turn-end frame ever arrives. A control that spins for ever is worse than one that admits it does not know. The desktop needs none of this: it gates its working row on bot.busy and never renders from the stream buffer. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * perf(ios): keep the engine-capability read off hydrate's critical path It only words the composer. The cursor commit — and with it the whole stream going live — must not wait on a request that says nothing about the transcript. Found while porting to Android, where blocking hydrate on it failed two Session tests outright. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(activity): a per-bot activity log, read from the two logs that already exist A bot's Activity panel: every tool it used and every approval it asked for, newest first, grouped by day, each row saying what ran ("Gmail · Search threads", "Ran a command"), the arguments the broker recorded, and the outcome — ran, failed, running, allowed, denied, or needs you. Nothing new is captured. server/activity.ts folds the per-thread runtime events (what ran, did it finish) with the fleet-wide decision log (what was asked, with which arguments, who allowed it), attaching an approval to the tool run it unblocked when the two land within a short window in the same thread. Connector calls never pass through the harness — the agent CLI talks to Composio's MCP endpoint directly — which is why this reads logs rather than tapping a proxy that does not exist. GET /api/bots/:id/activity is read-only over the bot's own threads (its DM and every task) plus the decision rows that name it. The panel sits beside the inspector and the computer panel, opens from a header button, re-reads when a turn settles or a card is answered, and stays available on remote clients since it is the user-facing view. Mobile gets the same API; a screen there is a follow-up. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * feat(outbound): sending on your behalf always asks, or spends a daily allowance A connector call that sends something — an email, a message, a post, an invite, a refund — is its own confirmation in every approval mode, Full access included. The relay every Composio call already passes through holds such a call on a "Send on your behalf?" card and waits for the answer; Deny (or nine minutes of silence) comes back to the bot as an ordinary tool error it can read and act on, never a transport failure it retries. A bot can instead be given a daily allowance, counted per local day on disk, after which the relay refuses with a message naming the limit. Every branch lands in the decision log under source "outbound", so the Activity panel shows it. shared/outbound.ts is the one definition of "outbound": the action part of a tool name, whether Composio's TOOLKIT_ACTION or a provider's mcp__server__action, with a read verb first meaning read and DRAFT meaning not sent. The auto-approve rules gain the same guard, so Approve for me and a remembered Always allow never wave a send through on a provider's own connectors either; explicit Full access on those stays a documented gap, since no request reaches the broker there. The bot record carries the policy (ask, the default, or allow with a cap), validated on PATCH like autoReview, with a read-only route for today's count. Bot settings get a "Sending on your behalf" control under the approval level, deliberately outside that selector so nothing implies Full access covers it. The card is a standard options card, so the phone apps already render it. Tests point the fixture's Composio Session MCP URL at the local stub, which needed one honest change: a backend the operator configured explicitly may hand back a Session on its own origin. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * feat(scopes): per-bot connection scopes, enforced at the connector relay Which connected apps a bot may use, and whether it may only read them. Absent means what it has always meant — every connected app, read and write — so nothing changes for a bot nobody has scoped. Present means a list: an app not on it is off for this bot, "read" refuses anything that is not a read, and a batch that mixes an allowed read with a forbidden write is refused whole rather than half-run. Enforced at the relay every Composio call already passes through, seeing through the session's meta tools the same way the outbound gate does, and checked before that gate: an app the bot may not touch is refused outright, never turned into a question for the person. A connection request for an app outside the bot's list is refused before any card appears. Every refusal lands in the decision log under source "connector-scope", so the Activity panel shows it, and the bot's prompt names what it may use so it does not spend a turn finding out. Bot settings gain a "Limit this bot to specific apps" switch inside the Connected apps card, with Off / Read / Read & write per connected app; an app the bot was scoped to that is no longer connected still shows, so a grant never silently disappears. null on the wire clears the scopes, normalized to an absent field the way `computer` already is. shared/connector-scopes.ts stands alone rather than importing from outbound.ts: shared/ is compiled by both the server (which needs .ts import extensions) and the app (which forbids them). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * feat(fallback): second accounts on an engine, and a per-bot fallback chain A second account on Claude or Codex is another instance of its driver with its own login directory (CLAUDE_CONFIG_DIR / CODEX_HOME under the data dir), so two Max plans sit side by side. POST /api/instances adds one beside the default fleet, inheriting the base engine's CLI override since a versioned binary is about the machine, not the account; DELETE removes only a profile, never a default-fleet instance. The instances section of config.json merges per id, so a removal is named explicitly to leave the file. App Settings → Engines gains "Add another account" and a Remove button on profile rows; the profile signs in from its own row like any engine. A bot's fallback chain says where a task carries on when its engine hits a usage limit, is rate limited, or cannot be reached. The turn.completed fold reads why the turn died from the thread's last runtime.error, and if the reason is one of those it moves the bot to the next available entry, posts a "switched to …" chip, and starts a control-plane continuation turn; the transcript replays into the new engine because it is fresh, and the person's message appears once. Hops are counted per thread so a chain whose every engine is down stops after one pass; a successful turn resets it. A turn the person stopped is never routed around. Bot settings → Model gains the ordered list. A subscription's usage limit is now classified as quota, not a 429 to retry through: the window is hours away, and the chain is the answer. The end-to-end test boots an isolated harness whose fixture Claude is scripted to die on a 429, adds a profile, chains it, sends one message, and watches the task finish on the second account. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * feat(team-memory): people, places, decisions and terms every bot in a section shares The layer between a bot's private MEMORY.md and the person's own section brief: bot-fed, person-reviewed, read by all. A bot that learns who someone is, where a document lives, what was decided, or what a term or nickname means proposes it with propose_team_memory. A place or a term lands at once, because the cost of a wrong one is a wasted lookup; a person or a decision waits for a "Remember this for the team?" card, because those shape what every teammate does next. Proposing an existing name again updates it rather than adding a twin. Every accepted entry rides into every section bot's prompt as a compact block under a byte budget, newest kept when it has to cut, with decisions dated — which is what lets a Chief of Staff answer "what happened today" without a digest routine. The Team map page gains a Memory dialog per section beside the shared context: what is waiting for a tap, then people, places, decisions and terms with inline editing, removal, and a way to add an entry by hand (the person's own entries never wait on the person). The card is a standard options card, so the phone apps render it already. Proposals and answers land in the decision log under source "team-memory". Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * feat(ios): Activity and Team memory screens, with the companion routes they call The phone twins of the desktop's Activity panel and Team map → Memory. From a bot's profile: "Activity" lists what the bot did, newest first by day, each row with the app and action in words, the recorded arguments, and an outcome chip (ran, failed, running, allowed, denied, needs you). "Team memory" lists the bot's section's shared people, places, decisions and terms, answers proposals waiting for a tap (Remember / Skip), removes entries with a swipe, and adds one by hand. Both are content surfaces; the sending policy, app scopes and fallback chain stay on the desktop, where the companion allowlist has always kept execution policy. The sidecar allowlist gains GET /api/bots/:id/activity and GET/POST/ PATCH/DELETE /api/team-memory, pinned in routes.test.ts. Two fixtures captured from a disposable harness pin the wire shapes for both phone suites: bot-activity.json (an empty page — a fixture harness runs no tools) and team-memory.json (one entry of each kind, added by hand). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs(mobile): design for a shared touch gesture layer on remote surfaces A pure GestureCore in each shared module turns normalised touch samples into abstract intents, so iOS and Android cannot drift and phase 2's VNC surface becomes a second sink rather than a second gesture layer. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs(mobile): implementation plan for the shared gesture core Twelve TDD tasks: the iOS core in full, the Kotlin port, and a shared parity fixture that fails the build when the two disagree. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(ios): gesture value types and viewport mapping ViewportMapping folds letterboxing, zoom and pan into one place, so a coordinate can only be got wrong once and is tested once. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(ios): click sequencing for direct-mode taps A sequence continues only while both the 450ms gap and the 0.02 slop hold, and wraps at three: a quadruple click means nothing to a browser. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(ios): long press, drag threshold and held-button drags tick(at:) is how a duration-based gesture stays testable in a core with no clock. A cancelled drag still releases, so the remote is never left holding a button nothing will lift. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(ios): trackpad mode with a virtual cursor and acceleration The finger is a rate control, not a position: the core owns the cursor and emits absolute coordinates, so both modes share one sink. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(ios): scroll, momentum and local zoom state Zoom stays local so a small target becomes reachable without reflowing the remote page. A scroll or a fired hold suppresses the click on lift, so a flick through links cannot open one. Records in the plan that parity must compare floats with tolerance: normalising through a division yields -0.09999999999999998 and -0.0. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(ios): driving gate and held-input flush driving is off by default, so a caller that forgets to set it fails safe rather than handing the remote away. flush() releases what is held and abandons momentum on release, backgrounding and disconnection. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * test(ios): shared gesture parity fixture and runner Eight cases across both modes in one JSON file the Kotlin runner will read verbatim. GestureIntent gets hand-written coding because Swift's synthesised enum shape nests under _0, which no Kotlin decoder reads. Verified the gate fails: widening multiClickWindow to 0.6 breaks the "tap after the window" case by name and step index. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(android): gesture value types and viewport mapping Mirrors CompanionCore's RemoteGestures, including the intent wire shape, so one parity fixture can serve both platforms. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(android): gesture core mirroring CompanionCore Click sequencing, long press and drags, trackpad cursor and acceleration, scroll and momentum, local zoom, driving gate and flush — 31 tests against the same behaviours the iOS suite asserts. Tasks 9-11 of the plan landed as one cycle: it is one file and one port, and Task 12's fixture is the gate that actually proves parity. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * test(android): run the shared gesture parity fixture No copy task needed: core/build.gradle.kts already points the test source set at ios/Tests/CompanionCoreTests/Fixtures, so one fixture directory already serves both platforms. Verifying the gate can fail caught a hole in the fixture itself. The long-press case ticked 0.4 then 0.5 and compared only the accumulated output, so a 300ms threshold produced the same three intents as 500ms and the sabotage passed. Added a case that stops short of the threshold and asserts nothing happens; the sabotage now fails by name. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(companion): per-device browser control capability browserControlAccess mirrors cloudDesktopAccess exactly: off on every new and migrated device, granted only from the loopback control page, revocation tears down live streams. It is a separate grant on purpose. A cloud desktop is a disposable VM; a bot's browser is normally signed into the person's real accounts, so a device trusted with the first must not inherit the second. No harness change was needed: request-auth re-runs the sidecar's own denyReason, so allowlisting the two routes opened both sides at once. Corrected the design doc, which claimed otherwise. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(ios): browser-live sink and input queue The sink is the only place normalised intents become device pixels, and it routes an unmodified single character to char rather than a raw keyDown the server would hold forever. The queue ports src/lib/browser-input-queue.ts: one request in flight, movement coalesced, wheel deltas summed, a 32-item ceiling that halts rather than banking input, and releases that survive the halt. settle() and drain() are deliberately different: drain abandons stale travel for hand-back, settle waits for everything. Writing the tests is what surfaced that they cannot be one method. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(android): browser-live sink and input queue Ports CompanionCore's sink and queue with the same assertions: pixel denormalisation, the char-not-keyDown rule for unmodified characters, movement coalescing, summed wheel deltas, the ceiling, and releases that survive a halt. A mutex stands in for the actor; the launch happens under the lock so two callers cannot both start a pump. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(mobile): browser-live transport and message decoding SSE frame stream plus the action channel on both platforms. The decoder drops an unknown message type rather than tearing down a stream someone is watching, and refuses a frame with no metadata, which cannot be mapped to coordinates anyway. Byte-at-a-time SSE parsing on iOS for the reason SSE.swift documents: AsyncLineSequence folds blank lines, which are what end an event. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(ios): browser control screen and touch adapter The adapter makes no decisions: raw touches become TouchSamples and a CADisplayLink drives the core's clock so long press and momentum work. A second finger flushes the tracked touch rather than half-tracking a pinch. The screen adds the modifier bar the design calls load-bearing, a locally drawn cursor for trackpad mode, a hidden field that turns soft keyboard text into char events, and take/release with a flush on backgrounding. The 429 from a full viewer table gets a real sentence. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(android): browser control screen and touch adapter Mirrors the iOS side: a pointerInput adapter that only produces TouchSamples, a frame-rate loop driving the core's clock, the modifier bar, a locally drawn cursor, and take/release with a drain on leave. The transport hangs off CompanionClient so it inherits the endpoint, scoped-IPv6 DNS and streaming timeouts rather than keeping a second copy of that setup. The Browser destination encodes and decodes with the rest of the stack, so restoring after process death does not silently drop the screen. Its entry point sits outside the cloud-desktop gate: any bot with a browser can be driven, not only cloud ones. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(mobile): typing on Android, cursor placement and pan Three gaps a self-review found after the screens compiled: - Android declared a typed buffer but had no field, so there was no way to type at all. Committed text now leaves as char; Backspace stays on the bar because an empty field reports no deletion. - The Android cursor was positioned against a hardcoded 1000px rather than the box it lives in, so it only landed right by accident. - Neither zoom path applied pan on Android, which stranded a zoomed-in person at the top-left with no way to reach the rest of the page. Also, on both platforms the page's own navigation could overwrite an address someone was halfway through typing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(mobile): make the browser stream actually decode, and 8 more A code review found the client halves were broken end to end. Most severe first: - The SSE decoder keyed on a `type` field inside the payload, but the server strips the type into the `event:` name and both SSE parsers discarded `event:` lines. Every message decoded to nil, so iOS never left "Connecting..." and Android never got a viewer id, which left Take control permanently disabled. Both parsers now carry the event name, and the decoders key on it — including `ready`, which is what the server actually calls the viewer-id message, plus `control` and `heartbeat`, which were not handled at all. - Two Kotlin string templates were written as literals ("Bearer \$it", "https://\$address"), so every Android browser request went out unauthenticated and scheme-less navigation went to a bogus host. - The Android tick clock and touch clock had different origins, and pointerInput restarts on a driving change — so after taking control every tap read as older than the long-press threshold and fired a right click instead. - Direct mode set `scrolled` on any nonzero move, so a tap that wobbled a pixel scrolled sub-pixel and suppressed its own click. Now behind the drag threshold, on both platforms. - pan() and the render transform measured against the view while the mapping used the aspect-fit drawn size. On a portrait phone showing a 16:9 page those differ by 3.6x, so zoomed taps landed far from the pixel touched. ViewportMapping now exposes drawnWidth/drawnHeight and all three use it. - The Android dispose-time release launched on a scope cancelled in the same pass, so it never left the phone. - The Android mapping was rebuilt only on layout, so a viewport other than the 1280x720 default never reached the core. - The sidecar's SSE scrub ceiling was 1 MiB against browser-live's 3 MiB frames; one large frame would have torn down the stream. The proxy test that covers this hardcoded 2 MiB and now derives from the constant, so it cannot rot the same way again. Regressions added for the wobble-tap and letterboxed-pan cases: the existing tests used a square viewport where drawn size equals view size, so neither bug could have been caught. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(mobile): revocation, stale clicks, held buttons and a pump race A second review pass found eight more. Most severe first: - Revoking browser control did not close a browser-live stream the device already had open, contrary to the comment promising it: disconnectDevice only ever reached /api/events and viewer relays. A phone kept watching a signed-in browser after the grant was taken away. The proxy now registers capability-gated streams per device and closes them on revoke, with a test. - A trackpad tap that never moved the finger emitted press/release with no move, so the sink stamped the click at its last coordinate — (0,0) on a fresh session — while the reticle sat where the person was aiming. Both platforms, and the parity fixture asserted the wrong shape. - iOS never called Coordinator.flush(), the only source of a release for a held button, so backgrounding or leaving mid-drag left it down. Android had this right; the design doc named the parity gap. - The Android dispose-time release enqueued into a queue built on the composition scope that the same pass cancels, so the pump never ran and drain() would have spun forever. It now sends directly. - A stale pump cleared `active` unconditionally, wiping the replacement clear() had just started and letting two pumps drain concurrently. - The Android trackpad reticle ignored letterboxing. - The 403 told people to use a Settings switch that does not exist; it now names the button, which every first-time user will need since the grant is off by default. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * test(companion): give proxy fixtures the browser capability field The field stays required on authenticate's return type, because the registry always supplies it. tsconfig.server.json type-checks these fixtures; tsc -b does not, which is why the packaged build caught this and the earlier check did not. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(mobile): show the server's refusal and let a dead stream retry The first hands-on test reported "browser control is off" after the grant was already on. The server path was fine: a device with the grant opens the stream, receives ready/control/status/frame, and take returns 200. The phone was at fault twice over: - The stream threw a bare status and discarded the response body, so every 403 read as "browser control is off" whatever the server said. Both clients now surface the sidecar's or harness's own error text. - Nothing restarted a stream once it failed, and toggling the grant deliberately disconnects the device. The screen sat dead until the person backed out. It now shows Try again, which starts a fresh viewer with no state carried over from the old one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(i18n): add complete Chinese localization across desktop and mobile - Add Simplified and Traditional Chinese translations across desktop, iOS, and Android - Integrate with companion mobile apps (Android Compose strings and iOS xcstrings) - Consolidate Android review resources into base and localized strings.xml - Fix BotThreadRow Compose status coloring and preserve upstream snooze logic - Update source-hashes.json and validate catalog completeness via generate-locale.mjs * fix(android): align the notification footer and localize the thread sheet - mobile_settings_notifications_footer said "while OpenMausMobile is connected" while OnboardingCopy.NOTIFICATIONS_BODY renders SettingsPolicy.NOTIFICATIONS_FOOTER ("while MausBot is connected"): OnboardingRoutingTest could not find the body text on screen, and the two surfaces showed different copy. The English resource now matches the constant byte for byte, with the Chinese catalogs following. - Route the delete/rename/snooze error text through localizedMobileCopy so the "Couldn't update this thread. Try again." fallback reaches the Chinese catalogs (CodeRabbit review). - Map "Rename thread" so the rename dialog heading translates (CodeRabbit review). - Give the snooze dialog's title, presets, "Stop snoozing", the working notice and Cancel real string resources with Simplified and Traditional Chinese. English resource values stay byte-identical to the pinned constants and test copy ("Rename thread", "Until 6 PM", "Until new activity", "Stop this thread before snoozing it.", "Cancel"). * fix(i18n): correct Chinese mistranslations found in cross-PR review Against the English source, eleven Simplified keys (and their Traditional twins, translated in the same pass) read wrong or dropped content: - installation rendered as "workspace" (voice.grok.sharedKey, settings.section.workspaces, settings.profiles.ownerOnly) - Servers / Installations section titles mistranslated (settings.section.desktopWorkspaces, workspaces.title) - bots mistranslated as "items" (team.moveSelected) - "Task folder" rendered as a workspace (composer.tray.privateWorkspace) - "Member (chat only)" gained an approval right it does not have (workspaces.chatOnly) - Threads mistranslated as a UI thread (backup.threads) - verb "Draft" used as a noun (botAccess.grants.verb.draft) - organization.disconnectWarning dropped the daily-backups sentence Terminology now follows each catalog's own established usage. * fix(i18n): unify Chinese terminology across desktop, Android, and iOS One glossary, applied everywhere the Chinese catalogs mix terms: - thread (and conversation) -> 对话 / 對話 (was 线程, 讨论串, 对话线程, 執行緒, 對話串 across the catalogs) - installation(s) -> 安装实例 / 安裝實例 (was mistranslated as 工作区) - workspace stays 工作区 / 工作區 where the English says workspace - default -> 默认 / 預設 (zh 缺省 merged into 默认) - "bot folders" -> 机器人文件夹 / 機器人資料夾 (was 工作区) - honorifics -> 你 (您 normalized away) - quotes: "..." in Simplified, 「...」 in Traditional - stray Traditional vocabulary in the Simplified catalog normalized (纪录->记录, 帐户->账户, 设置档->配置, 软体->软件, 网路->网络) 186 zh keys, 85 zh-tw keys, 52 Android string entries and 2 iOS xcstrings entries changed. English sources, placeholders and source hashes are untouched; node scripts/generate-locale.mjs --check passes. * feat(ios): Activity and Team memory screens, with the companion routes they call (#933) The phone twins of the desktop's Activity panel and Team map → Memory. From a bot's profile: "Activity" lists what the bot did, newest first by day, each row with the app and action in words, the recorded arguments, and an outcome chip (ran, failed, running, allowed, denied, needs you). "Team memory" lists the bot's section's shared people, places, decisions and terms, answers proposals waiting for a tap (Remember / Skip), removes entries with a swipe, and adds one by hand. Both are content surfaces; the sending policy, app scopes and fallback chain stay on the desktop, where the companion allowlist has always kept execution policy. The sidecar allowlist gains GET /api/bots/:id/activity and GET/POST/ PATCH/DELETE /api/team-memory, pinned in routes.test.ts. Two fixtures captured from a disposable harness pin the wire shapes for both phone suites: bot-activity.json (an empty page — a fixture harness runs no tools) and team-memory.json (one entry of each kind, added by hand). Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> * fix(companion): expose separate browser access grant in desktop settings * fix: harden mobile browser authorization and lifecycle --------- Co-authored-by: aivsomkar <aivsomkar@gmail.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: 择梦舟 <158067205+dreamfarer-space@users.noreply.github.com> Co-authored-by: LeaningLearner <1016823240@qq.com>
milind-soni
added a commit
that referenced
this pull request
Oct 3, 2026
* fix(ios): show and steer messages sent mid-turn
A message sent to a busy bot from the phone could simply disappear. The
harness answers such a send in one of three ways, and all three live only
in the POST's 202 body: the line landed, the engine took it INTO the
running turn (`steered`), or the harness is holding it off-transcript
until the turn settles (`queued`, with a `queueId`). The iOS client threw
that body away. A held message therefore left no trace anywhere — the
composer cleared and the words reappeared minutes later, or not at all
after a restart. Only the Claude driver can steer, so on every other
engine the queue is the only path and mid-turn sending looked broken.
Read the receipt, and give the phone what the desktop has had:
- `SendReceipt` decodes the 202 leniently — an older harness that answers
`{ok:true}` is a plain send, not a failure.
- `CompanionState.pendingQueued` holds what the harness is holding, keyed
by queueId. A drained line names its entry, so the ghost retires when
the real bubble lands; a drain that beats its own POST leaves a bounded
tombstone so the late receipt cannot resurrect it. Hydrates and page
merges reconcile for a window that slept through the drain.
- The chat draws held sends as dashed bubbles below the transcript, each
with its own cancel (DELETE …/queue/:id, newly allowed through the
sidecar for bots and rooms).
- The composer says which of the three will happen, and the send key
becomes a clock when the message will wait. With something already
waiting, the microphone becomes a green inject: the harness keeps its
steer queue across an interrupt, so stopping the turn is what makes
those words run now. Send stays available throughout.
- A line the engine took mid-turn is marked "sent mid-turn", which is why
the reply above it can read as if the bot had not seen it.
Inject is bot-only: the phone has no way to interrupt a room, and adding
one is a wider change than this bug. Rooms still get the ghost and cancel.
The steer e2e test now asserts the two fields a client needs from a
queued receipt, and that the drained line carries the same queueId.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(ios): do not fake a cancel a computer cannot perform
The sidecar answers 404 "no route: DELETE …" for a route it does not
allow, and the harness answers 404 "no such queued message" when the
entry is already gone. Treating those alike took the held message off the
phone while the computer still intended to run it — and it then arrived
anyway, which is worse than the vanishing this branch set out to fix.
Any computer whose sidecar predates the queue-cancel allowlist hits this,
including the currently released one.
Match the harness's own wording positively, so an unfamiliar 404 fails
safe: the ghost stays and the person is told the computer needs updating,
rather than being shown a cancel that did not happen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* feat: say Steer in words, above the chat bar
The mid-turn controls were glyphs: a clock on the send key, a green arrow
in the composer. Omkar read them on a real phone and said "don't add the
clock or the lightning, I don't understand" — and the held message itself,
drawn as a dashed outline, he could not see at all on a dark transcript.
So the queued message moves out of the transcript and sits directly above
the chat bar, where a thing you have not said yet belongs: the text, a
labelled `↳ Steer` button, and a bin. Steer stops the turn so those words
run now — the harness deliberately keeps its queue across an interrupt,
which is what makes stopping a send. The send key goes back to being one
arrow with one meaning; what will happen to the message is said in the
placeholder instead ("Sends into this turn" / "Sends after this turn").
Both platforms, because the desktop had the same puzzle: its green
"inject now" arrow is gone and its queued rows gain the same Steer button.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix: say Steering while the interrupt is still landing
Tapping Steer did nothing visible. Measured against a live codex turn, an
interrupt takes about 6.3 seconds to actually stop the stream — and for
those six seconds the button looked untouched while the bot kept talking,
which is indistinguishable from a broken button. Omkar read it as "it did
not steer at all", and he was right to.
The button now goes to "Steering…" and disables the moment it is pressed,
on both platforms. It clears when the queue drains OR when the turn ends —
both, so an interrupt that fails to stop the turn cannot leave the row
spinning for ever either.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(ios): retire the queued row, and stop streaming a dead turn
Two faults, seen together on a phone: a codex turn died mid-essay, and
from then on the chat streamed that half-written essay for ever while the
Steer button span for ever beside it.
The queued row was mine. A `bot` frame carrying a whole transcript
replaces `messages[…]` outright instead of appending, so it never runs the
retirement that `append` does — the held message stayed above the chat bar
long after its line had landed. The desktop has guarded this since the
feature shipped (reconcileSnapshotQueues on bot add/patch/task switch); the
port covered hydrate and page-merge and missed this path.
The stream was older. The live bubble was drawn whenever the buffer held
text, gated on nothing, and nothing cleared the buffer when a turn ended
without a settled reply — an engine that dies mid-sentence reports the
failure as activity, not as text. So the buffer kept its last tokens and
the bubble streamed them for ever. Now an idle bot clears the buffer, and
the bubble is gated on `busy` as well, so neither alone can strand it.
Also a floor under the spinner: it clears after twenty seconds even if
neither the drain nor the turn-end frame ever arrives. A control that
spins for ever is worse than one that admits it does not know.
The desktop needs none of this: it gates its working row on bot.busy and
never renders from the stream buffer.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* perf(ios): keep the engine-capability read off hydrate's critical path
It only words the composer. The cursor commit — and with it the whole
stream going live — must not wait on a request that says nothing about the
transcript. Found while porting to Android, where blocking hydrate on it
failed two Session tests outright.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* feat(activity): a per-bot activity log, read from the two logs that already exist
A bot's Activity panel: every tool it used and every approval it asked
for, newest first, grouped by day, each row saying what ran ("Gmail ·
Search threads", "Ran a command"), the arguments the broker recorded,
and the outcome — ran, failed, running, allowed, denied, or needs you.
Nothing new is captured. server/activity.ts folds the per-thread runtime
events (what ran, did it finish) with the fleet-wide decision log (what
was asked, with which arguments, who allowed it), attaching an approval
to the tool run it unblocked when the two land within a short window in
the same thread. Connector calls never pass through the harness — the
agent CLI talks to Composio's MCP endpoint directly — which is why this
reads logs rather than tapping a proxy that does not exist.
GET /api/bots/:id/activity is read-only over the bot's own threads (its
DM and every task) plus the decision rows that name it. The panel sits
beside the inspector and the computer panel, opens from a header button,
re-reads when a turn settles or a card is answered, and stays available
on remote clients since it is the user-facing view. Mobile gets the same
API; a screen there is a follow-up.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* feat(outbound): sending on your behalf always asks, or spends a daily allowance
A connector call that sends something — an email, a message, a post, an
invite, a refund — is its own confirmation in every approval mode, Full
access included. The relay every Composio call already passes through
holds such a call on a "Send on your behalf?" card and waits for the
answer; Deny (or nine minutes of silence) comes back to the bot as an
ordinary tool error it can read and act on, never a transport failure it
retries. A bot can instead be given a daily allowance, counted per local
day on disk, after which the relay refuses with a message naming the
limit. Every branch lands in the decision log under source "outbound",
so the Activity panel shows it.
shared/outbound.ts is the one definition of "outbound": the action part
of a tool name, whether Composio's TOOLKIT_ACTION or a provider's
mcp__server__action, with a read verb first meaning read and DRAFT
meaning not sent. The auto-approve rules gain the same guard, so Approve
for me and a remembered Always allow never wave a send through on a
provider's own connectors either; explicit Full access on those stays a
documented gap, since no request reaches the broker there.
The bot record carries the policy (ask, the default, or allow with a
cap), validated on PATCH like autoReview, with a read-only route for
today's count. Bot settings get a "Sending on your behalf" control under
the approval level, deliberately outside that selector so nothing
implies Full access covers it. The card is a standard options card, so
the phone apps already render it.
Tests point the fixture's Composio Session MCP URL at the local stub,
which needed one honest change: a backend the operator configured
explicitly may hand back a Session on its own origin.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* feat(scopes): per-bot connection scopes, enforced at the connector relay
Which connected apps a bot may use, and whether it may only read them.
Absent means what it has always meant — every connected app, read and
write — so nothing changes for a bot nobody has scoped. Present means a
list: an app not on it is off for this bot, "read" refuses anything
that is not a read, and a batch that mixes an allowed read with a
forbidden write is refused whole rather than half-run.
Enforced at the relay every Composio call already passes through, seeing
through the session's meta tools the same way the outbound gate does, and
checked before that gate: an app the bot may not touch is refused
outright, never turned into a question for the person. A connection
request for an app outside the bot's list is refused before any card
appears. Every refusal lands in the decision log under source
"connector-scope", so the Activity panel shows it, and the bot's prompt
names what it may use so it does not spend a turn finding out.
Bot settings gain a "Limit this bot to specific apps" switch inside the
Connected apps card, with Off / Read / Read & write per connected app;
an app the bot was scoped to that is no longer connected still shows,
so a grant never silently disappears. null on the wire clears the scopes,
normalized to an absent field the way `computer` already is.
shared/connector-scopes.ts stands alone rather than importing from
outbound.ts: shared/ is compiled by both the server (which needs .ts
import extensions) and the app (which forbids them).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* feat(fallback): second accounts on an engine, and a per-bot fallback chain
A second account on Claude or Codex is another instance of its driver
with its own login directory (CLAUDE_CONFIG_DIR / CODEX_HOME under the
data dir), so two Max plans sit side by side. POST /api/instances adds
one beside the default fleet, inheriting the base engine's CLI override
since a versioned binary is about the machine, not the account; DELETE
removes only a profile, never a default-fleet instance. The instances
section of config.json merges per id, so a removal is named explicitly
to leave the file. App Settings → Engines gains "Add another account"
and a Remove button on profile rows; the profile signs in from its own
row like any engine.
A bot's fallback chain says where a task carries on when its engine
hits a usage limit, is rate limited, or cannot be reached. The
turn.completed fold reads why the turn died from the thread's last
runtime.error, and if the reason is one of those it moves the bot to
the next available entry, posts a "switched to …" chip, and starts a
control-plane continuation turn; the transcript replays into the new
engine because it is fresh, and the person's message appears once. Hops
are counted per thread so a chain whose every engine is down stops
after one pass; a successful turn resets it. A turn the person stopped
is never routed around. Bot settings → Model gains the ordered list.
A subscription's usage limit is now classified as quota, not a 429 to
retry through: the window is hours away, and the chain is the answer.
The end-to-end test boots an isolated harness whose fixture Claude is
scripted to die on a 429, adds a profile, chains it, sends one message,
and watches the task finish on the second account.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* feat(team-memory): people, places, decisions and terms every bot in a section shares
The layer between a bot's private MEMORY.md and the person's own section
brief: bot-fed, person-reviewed, read by all. A bot that learns who
someone is, where a document lives, what was decided, or what a term or
nickname means proposes it with propose_team_memory. A place or a term
lands at once, because the cost of a wrong one is a wasted lookup; a
person or a decision waits for a "Remember this for the team?" card,
because those shape what every teammate does next. Proposing an existing
name again updates it rather than adding a twin. Every accepted entry
rides into every section bot's prompt as a compact block under a byte
budget, newest kept when it has to cut, with decisions dated — which is
what lets a Chief of Staff answer "what happened today" without a
digest routine.
The Team map page gains a Memory dialog per section beside the shared
context: what is waiting for a tap, then people, places, decisions and
terms with inline editing, removal, and a way to add an entry by hand
(the person's own entries never wait on the person). The card is a
standard options card, so the phone apps render it already. Proposals
and answers land in the decision log under source "team-memory".
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* feat(ios): Activity and Team memory screens, with the companion routes they call
The phone twins of the desktop's Activity panel and Team map → Memory.
From a bot's profile: "Activity" lists what the bot did, newest first by
day, each row with the app and action in words, the recorded arguments,
and an outcome chip (ran, failed, running, allowed, denied, needs you).
"Team memory" lists the bot's section's shared people, places, decisions
and terms, answers proposals waiting for a tap (Remember / Skip), removes
entries with a swipe, and adds one by hand. Both are content surfaces;
the sending policy, app scopes and fallback chain stay on the desktop,
where the companion allowlist has always kept execution policy.
The sidecar allowlist gains GET /api/bots/:id/activity and GET/POST/
PATCH/DELETE /api/team-memory, pinned in routes.test.ts. Two fixtures
captured from a disposable harness pin the wire shapes for both phone
suites: bot-activity.json (an empty page — a fixture harness runs no
tools) and team-memory.json (one entry of each kind, added by hand).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* docs(mobile): design for a shared touch gesture layer on remote surfaces
A pure GestureCore in each shared module turns normalised touch samples
into abstract intents, so iOS and Android cannot drift and phase 2's VNC
surface becomes a second sink rather than a second gesture layer.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* docs(mobile): implementation plan for the shared gesture core
Twelve TDD tasks: the iOS core in full, the Kotlin port, and a shared
parity fixture that fails the build when the two disagree.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* feat(ios): gesture value types and viewport mapping
ViewportMapping folds letterboxing, zoom and pan into one place, so a
coordinate can only be got wrong once and is tested once.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* feat(ios): click sequencing for direct-mode taps
A sequence continues only while both the 450ms gap and the 0.02 slop
hold, and wraps at three: a quadruple click means nothing to a browser.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* feat(ios): long press, drag threshold and held-button drags
tick(at:) is how a duration-based gesture stays testable in a core with
no clock. A cancelled drag still releases, so the remote is never left
holding a button nothing will lift.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* feat(ios): trackpad mode with a virtual cursor and acceleration
The finger is a rate control, not a position: the core owns the cursor
and emits absolute coordinates, so both modes share one sink.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* feat(ios): scroll, momentum and local zoom state
Zoom stays local so a small target becomes reachable without reflowing
the remote page. A scroll or a fired hold suppresses the click on lift,
so a flick through links cannot open one.
Records in the plan that parity must compare floats with tolerance:
normalising through a division yields -0.09999999999999998 and -0.0.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* feat(ios): driving gate and held-input flush
driving is off by default, so a caller that forgets to set it fails safe
rather than handing the remote away. flush() releases what is held and
abandons momentum on release, backgrounding and disconnection.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* test(ios): shared gesture parity fixture and runner
Eight cases across both modes in one JSON file the Kotlin runner will
read verbatim. GestureIntent gets hand-written coding because Swift's
synthesised enum shape nests under _0, which no Kotlin decoder reads.
Verified the gate fails: widening multiClickWindow to 0.6 breaks the
"tap after the window" case by name and step index.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* feat(android): gesture value types and viewport mapping
Mirrors CompanionCore's RemoteGestures, including the intent wire shape,
so one parity fixture can serve both platforms.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* feat(android): gesture core mirroring CompanionCore
Click sequencing, long press and drags, trackpad cursor and
acceleration, scroll and momentum, local zoom, driving gate and flush —
31 tests against the same behaviours the iOS suite asserts.
Tasks 9-11 of the plan landed as one cycle: it is one file and one port,
and Task 12's fixture is the gate that actually proves parity.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* test(android): run the shared gesture parity fixture
No copy task needed: core/build.gradle.kts already points the test
source set at ios/Tests/CompanionCoreTests/Fixtures, so one fixture
directory already serves both platforms.
Verifying the gate can fail caught a hole in the fixture itself. The
long-press case ticked 0.4 then 0.5 and compared only the accumulated
output, so a 300ms threshold produced the same three intents as 500ms
and the sabotage passed. Added a case that stops short of the threshold
and asserts nothing happens; the sabotage now fails by name.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* feat(companion): per-device browser control capability
browserControlAccess mirrors cloudDesktopAccess exactly: off on every new
and migrated device, granted only from the loopback control page,
revocation tears down live streams.
It is a separate grant on purpose. A cloud desktop is a disposable VM; a
bot's browser is normally signed into the person's real accounts, so a
device trusted with the first must not inherit the second.
No harness change was needed: request-auth re-runs the sidecar's own
denyReason, so allowlisting the two routes opened both sides at once.
Corrected the design doc, which claimed otherwise.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* feat(ios): browser-live sink and input queue
The sink is the only place normalised intents become device pixels, and
it routes an unmodified single character to char rather than a raw
keyDown the server would hold forever.
The queue ports src/lib/browser-input-queue.ts: one request in flight,
movement coalesced, wheel deltas summed, a 32-item ceiling that halts
rather than banking input, and releases that survive the halt.
settle() and drain() are deliberately different: drain abandons stale
travel for hand-back, settle waits for everything. Writing the tests is
what surfaced that they cannot be one method.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* feat(android): browser-live sink and input queue
Ports CompanionCore's sink and queue with the same assertions: pixel
denormalisation, the char-not-keyDown rule for unmodified characters,
movement coalescing, summed wheel deltas, the ceiling, and releases that
survive a halt.
A mutex stands in for the actor; the launch happens under the lock so
two callers cannot both start a pump.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* feat(mobile): browser-live transport and message decoding
SSE frame stream plus the action channel on both platforms. The decoder
drops an unknown message type rather than tearing down a stream someone
is watching, and refuses a frame with no metadata, which cannot be
mapped to coordinates anyway.
Byte-at-a-time SSE parsing on iOS for the reason SSE.swift documents:
AsyncLineSequence folds blank lines, which are what end an event.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* feat(ios): browser control screen and touch adapter
The adapter makes no decisions: raw touches become TouchSamples and a
CADisplayLink drives the core's clock so long press and momentum work.
A second finger flushes the tracked touch rather than half-tracking a
pinch.
The screen adds the modifier bar the design calls load-bearing, a
locally drawn cursor for trackpad mode, a hidden field that turns soft
keyboard text into char events, and take/release with a flush on
backgrounding. The 429 from a full viewer table gets a real sentence.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* feat(android): browser control screen and touch adapter
Mirrors the iOS side: a pointerInput adapter that only produces
TouchSamples, a frame-rate loop driving the core's clock, the modifier
bar, a locally drawn cursor, and take/release with a drain on leave.
The transport hangs off CompanionClient so it inherits the endpoint,
scoped-IPv6 DNS and streaming timeouts rather than keeping a second copy
of that setup.
The Browser destination encodes and decodes with the rest of the stack,
so restoring after process death does not silently drop the screen. Its
entry point sits outside the cloud-desktop gate: any bot with a browser
can be driven, not only cloud ones.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(mobile): typing on Android, cursor placement and pan
Three gaps a self-review found after the screens compiled:
- Android declared a typed buffer but had no field, so there was no way
to type at all. Committed text now leaves as char; Backspace stays on
the bar because an empty field reports no deletion.
- The Android cursor was positioned against a hardcoded 1000px rather
than the box it lives in, so it only landed right by accident.
- Neither zoom path applied pan on Android, which stranded a zoomed-in
person at the top-left with no way to reach the rest of the page.
Also, on both platforms the page's own navigation could overwrite an
address someone was halfway through typing.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(mobile): make the browser stream actually decode, and 8 more
A code review found the client halves were broken end to end. Most
severe first:
- The SSE decoder keyed on a `type` field inside the payload, but the
server strips the type into the `event:` name and both SSE parsers
discarded `event:` lines. Every message decoded to nil, so iOS never
left "Connecting..." and Android never got a viewer id, which left
Take control permanently disabled. Both parsers now carry the event
name, and the decoders key on it — including `ready`, which is what
the server actually calls the viewer-id message, plus `control` and
`heartbeat`, which were not handled at all.
- Two Kotlin string templates were written as literals ("Bearer \$it",
"https://\$address"), so every Android browser request went out
unauthenticated and scheme-less navigation went to a bogus host.
- The Android tick clock and touch clock had different origins, and
pointerInput restarts on a driving change — so after taking control
every tap read as older than the long-press threshold and fired a
right click instead.
- Direct mode set `scrolled` on any nonzero move, so a tap that wobbled
a pixel scrolled sub-pixel and suppressed its own click. Now behind
the drag threshold, on both platforms.
- pan() and the render transform measured against the view while the
mapping used the aspect-fit drawn size. On a portrait phone showing a
16:9 page those differ by 3.6x, so zoomed taps landed far from the
pixel touched. ViewportMapping now exposes drawnWidth/drawnHeight and
all three use it.
- The Android dispose-time release launched on a scope cancelled in the
same pass, so it never left the phone.
- The Android mapping was rebuilt only on layout, so a viewport other
than the 1280x720 default never reached the core.
- The sidecar's SSE scrub ceiling was 1 MiB against browser-live's 3 MiB
frames; one large frame would have torn down the stream. The proxy
test that covers this hardcoded 2 MiB and now derives from the
constant, so it cannot rot the same way again.
Regressions added for the wobble-tap and letterboxed-pan cases: the
existing tests used a square viewport where drawn size equals view size,
so neither bug could have been caught.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(mobile): revocation, stale clicks, held buttons and a pump race
A second review pass found eight more. Most severe first:
- Revoking browser control did not close a browser-live stream the
device already had open, contrary to the comment promising it:
disconnectDevice only ever reached /api/events and viewer relays. A
phone kept watching a signed-in browser after the grant was taken
away. The proxy now registers capability-gated streams per device and
closes them on revoke, with a test.
- A trackpad tap that never moved the finger emitted press/release with
no move, so the sink stamped the click at its last coordinate —
(0,0) on a fresh session — while the reticle sat where the person was
aiming. Both platforms, and the parity fixture asserted the wrong
shape.
- iOS never called Coordinator.flush(), the only source of a release
for a held button, so backgrounding or leaving mid-drag left it down.
Android had this right; the design doc named the parity gap.
- The Android dispose-time release enqueued into a queue built on the
composition scope that the same pass cancels, so the pump never ran
and drain() would have spun forever. It now sends directly.
- A stale pump cleared `active` unconditionally, wiping the replacement
clear() had just started and letting two pumps drain concurrently.
- The Android trackpad reticle ignored letterboxing.
- The 403 told people to use a Settings switch that does not exist;
it now names the button, which every first-time user will need since
the grant is off by default.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* test(companion): give proxy fixtures the browser capability field
The field stays required on authenticate's return type, because the
registry always supplies it. tsconfig.server.json type-checks these
fixtures; tsc -b does not, which is why the packaged build caught this
and the earlier check did not.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(mobile): show the server's refusal and let a dead stream retry
The first hands-on test reported "browser control is off" after the
grant was already on. The server path was fine: a device with the grant
opens the stream, receives ready/control/status/frame, and take returns
200. The phone was at fault twice over:
- The stream threw a bare status and discarded the response body, so
every 403 read as "browser control is off" whatever the server said.
Both clients now surface the sidecar's or harness's own error text.
- Nothing restarted a stream once it failed, and toggling the grant
deliberately disconnects the device. The screen sat dead until the
person backed out. It now shows Try again, which starts a fresh
viewer with no state carried over from the old one.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* feat(i18n): add complete Chinese localization across desktop and mobile
- Add Simplified and Traditional Chinese translations across desktop, iOS, and Android
- Integrate with companion mobile apps (Android Compose strings and iOS xcstrings)
- Consolidate Android review resources into base and localized strings.xml
- Fix BotThreadRow Compose status coloring and preserve upstream snooze logic
- Update source-hashes.json and validate catalog completeness via generate-locale.mjs
* fix(android): align the notification footer and localize the thread sheet
- mobile_settings_notifications_footer said "while OpenMausMobile is
connected" while OnboardingCopy.NOTIFICATIONS_BODY renders
SettingsPolicy.NOTIFICATIONS_FOOTER ("while MausBot is connected"):
OnboardingRoutingTest could not find the body text on screen, and the two
surfaces showed different copy. The English resource now matches the
constant byte for byte, with the Chinese catalogs following.
- Route the delete/rename/snooze error text through localizedMobileCopy so
the "Couldn't update this thread. Try again." fallback reaches the Chinese
catalogs (CodeRabbit review).
- Map "Rename thread" so the rename dialog heading translates (CodeRabbit
review).
- Give the snooze dialog's title, presets, "Stop snoozing", the working
notice and Cancel real string resources with Simplified and Traditional
Chinese.
English resource values stay byte-identical to the pinned constants and test
copy ("Rename thread", "Until 6 PM", "Until new activity",
"Stop this thread before snoozing it.", "Cancel").
* fix(i18n): correct Chinese mistranslations found in cross-PR review
Against the English source, eleven Simplified keys (and their Traditional
twins, translated in the same pass) read wrong or dropped content:
- installation rendered as "workspace" (voice.grok.sharedKey,
settings.section.workspaces, settings.profiles.ownerOnly)
- Servers / Installations section titles mistranslated
(settings.section.desktopWorkspaces, workspaces.title)
- bots mistranslated as "items" (team.moveSelected)
- "Task folder" rendered as a workspace (composer.tray.privateWorkspace)
- "Member (chat only)" gained an approval right it does not have
(workspaces.chatOnly)
- Threads mistranslated as a UI thread (backup.threads)
- verb "Draft" used as a noun (botAccess.grants.verb.draft)
- organization.disconnectWarning dropped the daily-backups sentence
Terminology now follows each catalog's own established usage.
* fix(i18n): unify Chinese terminology across desktop, Android, and iOS
One glossary, applied everywhere the Chinese catalogs mix terms:
- thread (and conversation) -> 对话 / 對話 (was 线程, 讨论串, 对话线程,
執行緒, 對話串 across the catalogs)
- installation(s) -> 安装实例 / 安裝實例 (was mistranslated as 工作区)
- workspace stays 工作区 / 工作區 where the English says workspace
- default -> 默认 / 預設 (zh 缺省 merged into 默认)
- "bot folders" -> 机器人文件夹 / 機器人資料夾 (was 工作区)
- honorifics -> 你 (您 normalized away)
- quotes: "..." in Simplified, 「...」 in Traditional
- stray Traditional vocabulary in the Simplified catalog normalized
(纪录->记录, 帐户->账户, 设置档->配置, 软体->软件, 网路->网络)
186 zh keys, 85 zh-tw keys, 52 Android string entries and 2 iOS
xcstrings entries changed. English sources, placeholders and source
hashes are untouched; node scripts/generate-locale.mjs --check passes.
* feat(ios): Activity and Team memory screens, with the companion routes they call (#933)
The phone twins of the desktop's Activity panel and Team map → Memory.
From a bot's profile: "Activity" lists what the bot did, newest first by
day, each row with the app and action in words, the recorded arguments,
and an outcome chip (ran, failed, running, allowed, denied, needs you).
"Team memory" lists the bot's section's shared people, places, decisions
and terms, answers proposals waiting for a tap (Remember / Skip), removes
entries with a swipe, and adds one by hand. Both are content surfaces;
the sending policy, app scopes and fallback chain stay on the desktop,
where the companion allowlist has always kept execution policy.
The sidecar allowlist gains GET /api/bots/:id/activity and GET/POST/
PATCH/DELETE /api/team-memory, pinned in routes.test.ts. Two fixtures
captured from a disposable harness pin the wire shapes for both phone
suites: bot-activity.json (an empty page — a fixture harness runs no
tools) and team-memory.json (one entry of each kind, added by hand).
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
* fix(companion): expose separate browser access grant in desktop settings
* fix: harden mobile browser authorization and lifecycle
* test: align integration fixtures with consent and reconnect readiness
* test: align integration fixtures with consent and reconnect readiness
---------
Co-authored-by: aivsomkar <aivsomkar@gmail.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: 择梦舟 <158067205+dreamfarer-space@users.noreply.github.com>
Co-authored-by: LeaningLearner <1016823240@qq.com>
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In plain language
The phone half of #903: two screens, reached from a bot's profile.
The sending policy, app scopes, and fallback chain from #903 are not ported, on purpose: a paired phone may change a bot's model and profile but no other bot settings (
companion/src/routes.ts), so execution policy stays on the desktop. The new approval cards from #903 already rendered on the phone before this PR.What changed
companion/src/routes.ts: allowlistGET /api/bots/:id/activityandGET/POST/PATCH/DELETE /api/team-memory, pinned inroutes.test.ts.ios/Sources/CompanionCore:ActivityRow,ActivityPage,TeamMemoryEntry,TeamMemoryPage,TeamMemoryEdit; client callsactivity,teamMemory,addTeamMemory,answerTeamMemory,updateTeamMemory,removeTeamMemory.ios/App:BotActivityView,TeamMemoryView, two rows in the agent profile, session wrappers.bot-activity.jsonandteam-memory.json, captured from a disposable harness byscripts/capture-companion-fixtures.mjs(extended to record both). Android's suite reads the same files.Test plan
swift test: 345 tests passing, including decoding both fixtures and the client paths, queries and bodiesxcodegen generate+ simulator compile gate (xcodebuild … -sdk iphonesimulator CODE_SIGNING_ALLOWED=NO build): succeededroutes.test.ts: 86 passingStacked on #903 (base
feat/trust-phase-1).Platforms
🤖 Generated with Claude Code