[tebiggs]

The phone's T3 Code server listens only on loopback and was never linked to T3 Connect, so its threads showed only in the app on that phone. This adds an opt-in Share with your other devices control with three choices (Off, View only, Full control), in phone setup (once the phone is connected) and on the phone's environment page.

• View only or Full control: a dialog says what another device gets. Then the app installs cloudflared in Ubuntu through the server's relay client installer, stores the mode on the server, links the server to the T3 Connect account it's signed in to, and checks for up to a minute that the tunnel answers. Sharing can be turned off during that check.
• View only is enforced by the server. Each T3 Connect credential's scopes are chosen when it's minted, from a mode the server stores. A View only device gets orchestration:read and nothing else: it can read threads, diffs of a thread's turns, projects, pull requests and open previews. It can't send messages, answer approvals, stop agents, or use terminals or files. Hosts that never stored a mode keep the full scopes.
• orchestration:read is now actually read-only, on every host. Some read methods had side effects, so this tightens them for any session without orchestration:operate: mcpApps.readResource, device.detail and ACP registry session and provider listing now need operate. device.list gives the passive view, server.refreshProviders returns what's already known, and VCS status stays local, with no remote polling or auto-pull.
• Changing the mode signs out every other client and revokes pairing links, in one step on the server (POST /api/connect/sharing-mode, which needs relay:write and access:write). The mode is stored first. A flag stays set until the sign-out finishes, so a failed sign-out shows on the phone instead of reading as done, and tapping the mode again retries. Mints, credential exchanges, pairing links, MCP approvals, preview sockets and device sockets are all covered, so nobody keeps the old access.
• Off: stops the tunnel, signs out every other client, revokes pairing links and deregisters the phone. Anything another device changed or installed while it was shared stays, and the dialog says so.
• Signing out or switching T3 Connect accounts ends sharing, or marks it to end when the server is next reachable. The old account keeps listing the phone until it signs in here again, because deregistering needs that sign-in.
• Remove and Reinstall deregister using a saved record of the account, so they work with the server down, and they tell the user when they can't.
• The server keeps listening on 127.0.0.1. cloudflared reaches it there and connects out.
• Ongoing activity skips the phone's server. It linked every paired server with a managed tunnel, which would share the phone without the switch.

Ask each time is now decided on the phone. The Android bridge shows a prompt with the command and its whole request for each run, and no answer within a minute counts as no. It used to be only a thread prompt, which a remote client can answer, or skip by calling the bridge directly from a terminal. This changes local use too: Claude Code's ask rules are gone, so the phone is the one place that asks, for every provider.

One controller owns every change to sharing, working from a record saved before the work starts. An unfinished stop keeps the switch on and retries when the server or the app comes back. Removing the phone's connection stops sharing first, or asks.

Changes from the plan in #13

• The app links the server instead of running t3 connect in proot. The app is already signed in to T3 Connect, and the server's link API is the flow web and mobile use for other hosts. This avoids a second device-code sign-in inside Ubuntu and the relay client's install prompt, which needs a terminal the runtime doesn't have. The server also doesn't need a restart.
• The tunnel survives restarts. A t3 connect link releases its tunnel each time the server stops, and a new tunnel takes one to two minutes to resolve. App links keep their tunnel and recover it by credential.
• feat(mobile): run the phone's server and Claude Code inside the app, replacing Termux #11 removed Termux, so only the in-app runtime needs covering.

Open questions from #13

• Does it work inside proot? The sign-in question no longer applies. Still untested: whether cloudflared (Go, static linux-arm64) runs under proot on Android, and whether it stops when sharing is turned off.
• How do other clients show the phone while its server is down? They show it offline, like any linked host. T3 Connect's idle cleanup drops the tunnel after a few minutes offline, and the server gets a replacement at the same address when it starts again (docs/user/remote-access.md).

Known limits

• View only doesn't hide threads from the account. Anyone signed in to it can read every thread, including any secrets in them, and the pull requests the phone's GitHub sign-in can see. Left out of View only: filesystem:read (so the Review panel's local diffs and file browsing don't work), terminal:read, diagnostics:read, relay:read and access:read. A viewer also sees no remote ahead or behind counts unless another client is polling, and MCP apps in a thread can't read their server's resources.
• The tunnel address stays public in both modes. These stay reachable: the server descriptor and web files with no sign-in, the mint endpoint with a relay-signed proof, guest links, and webhooks with the token in their URL. Protected routes reject requests without credentials, and the relay's own account check is trusted, not verified, because its code isn't in this repo.
• If a mode change and the read after it both fail, the phone keeps showing the old mode next to the failure warning. A viewer's device panel shows an authorization error, but the phone has no device hub by default.
• Switching to View only doesn't undo anything. What a device changed or set up under Full control stays, including guest links and scheduled tasks. Signed asset and upload URLs it already had stay valid until they expire (about ten minutes for uploads), and a preview action already running when its socket closes can finish.
• A View only change needs a server that has it. The phone installs its server from the fork's releases, so an older server is refused View only with a prompt to update, and Full control still works on it.
• Full control is full remote control of the phone's server. Agent access protects Android data and actions, not Ubuntu or /sdcard, which a remote terminal reaches directly.
• proot isn't a security boundary, so Agent access may not hold against someone with a remote terminal. Guest processes run under the app's Android user with /dev and /proc. Direct Binder calls could use Android permissions the app already has, and /proc or untranslated syscalls could reach the app's private files. Neither has been tried on a device. The share dialog says this, and it needs a device test.
• The record holds one listing. Reinstalling while signed out of the old account and then sharing under another leaves the old listing on the old account, offline and with a dead credential, until it's deregistered under Settings > T3 Connect. Keeping a list of them isn't worth it for one phone.
• A link that times out could still finish on the server just after the rollback's unlink, with its listing already removed. Nothing retries that automatically. The switch would read as on the next time the screen opens, and turning it off clears it.
• getResult on the shared preference atom waits for every write in progress, so another preference's failed write can fail a sharing step, which then retries, and a sharing record may stay visible after its write failed. The switch reads the server and treats a stopping record as on, so this can't make a shared phone look off.
• Loading preferences has no deadline: deciding without the record is the unsafe part. If storage never settled, sharing changes would wait behind it, along with the rest of the app's preferences.
• If preferences fail to load at launch while the connection catalog is still loading, a sign-out's stop finds no phone and reports success, so the tunnel stays up. This needs a storage failure, and turning the switch off still works.
• Browser session cookies have no Secure flag (existing server behaviour, not changed here).

Testing

Thirteen rounds of Codex GPT-6.1 Sol security review: six on the first version, approving at 6c9337a, then seven on View only, ending with no blocking or minor findings at 41fffa7. Those seven found preview and device sockets outliving a mode change, MCP approvals redeemed after one, requests in flight during one, MCP apps reading any resource on their server, and read methods that could start the device hub, install or start providers, or auto-pull. All are fixed. Severity: blocking means a realistic way to expose the phone to someone unintended or to lose control of the switch, or a View only session exceeding read access. Rare races and defences against someone who already has the account are minor. A device that just held Full control already had a root terminal.

vp run check:changed passes. Tests cover the scopes minted per mode, including an unreadable or unknown stored mode, the mode-change ordering and its races with mints and exchanges, failed sign-outs, refused routes for a read-only session, MCP approvals from before a change, and preview and device sockets closing with their session.

I ran a dev server with a read-only session. RPC refused orchestration.dispatchCommand, terminal.open, terminal.write and projects.readFile; HTTP refused sharing mode, unlink, pairing, client revocation and trace export. In a browser the thread rendered with Send disabled, and Attach, Fork, Settle and project scripts were hidden. The approval cards were checked in code and through refused RPC, not by answering one in a browser.

Nothing has run on a real phone, including the new mode control, which needs the Android app with the phone runtime and a T3 Connect sign-in. Screenshots weren't taken for the same reason. Whether cloudflared runs under proot and stops on Off is still untested. The Kotlin approval prompt has no tests.

Also in this PR: agentContextBudget.json moves to the measured 46039 bytes. A clean main checkout measures the same, so that mismatch came from main.

🤖 Generated with Claude Code