feat(web): confirm server updates when work is running

[incognitojam]

Note

The in-app Update server action now checks the server for running work before restarting it, using the same activity check and dialog wording as desktop quit and restart. Idle servers update without a dialog.

The Update server action restarted a connected server without checking what was running on it. The only confirmation was a fixed prompt for desktop-hosted servers, so updating a CLI or service-hosted server could interrupt an agent turn, a background task such as a Claude monitor, or a terminal command, including work started from another device. Desktop quit and restart already check this through the server's host activity (#362), but that check was limited to backends the desktop app hosts.

Behavior

• Before updating, the client reads the server's host activity: active and waiting threads (including background work), running terminal commands, and terminals that could not be inspected.
• Idle servers update immediately. Otherwise a confirmation lists what will be interrupted, for example "Update the Lab server with running work?" followed by "1 thread will be interrupted." Cancel leaves the server running.
• With Continue threads after restarts on, threads that continuation will resume are listed as continuing after the restart, and every other active thread as interrupted. That includes a thread whose turn has finished but that still has background work such as a monitor, which continuation does not resume today (upstream pingdotgg/t3code#13400, tracked in Continue threads with background work after a server restart #454).
• If the check fails or takes longer than five seconds, including on servers that predate this change, the dialog says activity could not be checked and still lets the user continue.
• Desktop-hosted servers keep their unconditional relaunch confirmation, which now also lists running work.

Implementation

• listContinuableThreads in serverRuntimeStartup.ts is now the one place that selects threads for continuation. The self-update marking step uses it, and the activity check reports how many active threads it selects as continuableSessions. If upstream widens the selection, the dialog changes with it.
• server.getHostActivity is a new WebSocket RPC (orchestration read scope) that returns the existing inspectHostActivity result. It uses the WebSocket rather than the existing /api/environment/activity HTTP endpoint so it works over relay and tunnel connections as well as direct ones.
• describeHostActivity in @t3tools/shared/hostActivity turns one or more activity results into the dialog lines and the kind of confirmation needed. The desktop shutdown guard and the web update action both use it, so their wording stays in sync, and a multi-server update action can pass several results in and get combined counts. Desktop quit and restart output is unchanged.
• User docs, the styal differences overview, and the fork feature ledger describe the new check.

Screenshots

The same thread, with a Codex turn and a terminal command both running. Before this change, Update restarted the server immediately. It now asks first.

Before: Update restarts the server immediately	After: confirmation lists the running work

With Continue threads after restarts on, a running turn that continuation will resume is listed as continuing:

Validation

Real client: a web dev server on isolated synthetic state, with the client forced to see the server as behind and supporting in-app updates. The server update RPCs were stubbed to fail, so confirming did not install anything. None of that is part of this diff.

• Idle server, Update from Settings → Connections: no dialog; the update request was sent.
• sleep 600 running in a thread terminal, Update from the chat banner: "Update the server with running work? 1 terminal session will be interrupted." Cancel sent no update request.
• Same state, Update from Settings → Connections: the same dialog. Confirm sent the update request.
• A real Codex turn running sleep 120 plus the terminal: "1 thread will be interrupted." and "1 terminal session will be interrupted."
• A real Codex turn with Continue threads after restarts on: "1 thread will continue after the restart." With the setting off, the same turn: "1 thread will be interrupted."
• Automated tests:
  • Server: host activity tests count continuable threads only among active threads, and the existing continuation-marking tests pass against the shared selection.
  • Server: a WebSocket test calls server.getHostActivity against the app under test with a running provider session and mocked terminal inspection, and receives those counts.
  • Web: component tests cover idle servers updating without a dialog, Cancel leaving the server alone, Confirm starting the update, and a failed activity check still asking. Logic tests cover the dialog text for server and desktop-app updates.
  • Shared: tests cover adding up counts across hosts, waiting threads, continuing versus interrupted threads, uninspected terminals, and failed or missing host checks.
  • Desktop: the existing shutdown-guard suite passes unchanged against the shared helper.
  • Typecheck passes for contracts, shared, client-runtime, server, desktop, and web.

Not exercised in a real client: a thread waiting for approval, a thread with only background work, a remote desktop-app update, and a real install after Confirm. These are covered by the automated tests above, except the real install, which this change does not touch.

---

Written by an agent (Claude Code, claude-opus-5-5).