# Stop reaches an older background command

Target: [#16867](https://github.com/pingdotgg/t3code/pull/16867).
Verified head: [261a08b](https://github.com/voltcrash/t3cocoa/commit/261a08b28fcb02112cae0b9279bac46f7d5f7d4c).

## Before and after

Before: a bounded initial snapshot omitted an old running command. The shell could report pending work while the client Stop path saw none and returned without interrupting it.

After: initial snapshots retain actionable old work as control state outside visible history. Command output is clipped in SQL before decode, wire projection preserves the persistent-monitor discriminator, and history paging places the item once using its current state. Terminal, rolled-back and persistent-monitor work is excluded. Existing provider ownership routing is preserved.

## Integrated Linux web/Codex proof

The primary agent used the isolated development server and a disposable fixture thread, with the real web client and native Codex provider. No developer database was opened for writing.

1. Asked Codex to start a background Node command that prints its PID and remains alive, without file edits. Codex started PID 852526 in the fixture worktree. Its exact command line and worktree were checked before observing it.
2. Finished that turn, then completed ten further real provider turns. The command belonged to run 3; the latest run was 13. All runs 3 through 13 were completed, so Stop was not stopping active generation.
3. Cold-reloaded the same thread. The initial visible history no longer contained the old prompt or command row, but the running-work strip still showed the command and Stop.
4. Registered an event-driven Linux pidfd exit observer for that exact fixture process, then clicked the real Stop button. No manual process signal was sent.
5. The pidfd observer recorded PROCESS_EXIT_EVENT. The running-work strip and Stop disappeared. Read-only inspection of the isolated database showed a completed run_interrupt_request on latest run 13 (event sequence 465), followed by the command_execution item becoming interrupted on owning run 3 (sequences 466 and 468). Latest run 13 remained completed.
6. Loaded older history through the actual scroll/paging path and expanded the old turn. The old prompt, assistant result and command were available again; the command appeared once. The focused history-merge tests separately verify historical position and the live interrupted state when a stale page arrives.

This joins a real bounded server snapshot, client Stop, server effect-worker routing, native provider interruption and OS process exit. The fixture command ended through Stop.

The VM browser capture renders icons and controls but omits text. The screenshot was inspected and rejected as unreadable. Evidence therefore uses actual DOM observations, persisted events, OS process exit and focused tests; there is no usable screenshot/video attached.

## Focused verification

- Original added cases: four across four files; retained/rebuilt cases: three across three existing files, plus an extension of the existing client Stop status family. Removed the duplicate history-bounding case.
- Six focused suites: 151 cases before the takeover test reduction, 150 after. All 150 pass on the verified head. The Opus reviewer independently repeated all 150 successfully.
- Exact-main comparison: the SQL snapshot, persistent-input wire and history-merge regressions each fail an assertion with all five production files restored to main. Restoring the implementation makes them pass; production bytes were hash-checked.
- Existing effect-worker integration cases verify earlier owning-provider routing, including later settled/failed/queued runs.
- Scoped lint/format and server/client-runtime typechecks pass. The three existing ws.ts lint warnings are unrelated to the change.
- One independent full-diff review round by Claude Opus 5.5 and GPT-6 Sol found no blocking findings. Historical monitor and NULL-predicate issues were checked against the current implementation. Withdrawn requests for an unrelated handler refactor and a hard cap on mandatory control items were not reintroduced.

## Limits

Live proof covers local Linux web plus Codex. Other provider adapters, relay/tunnel, remote browsers, native macOS/Windows, packaged Electron, iOS and Android were not exercised. Web, desktop and mobile share the changed client-runtime path, but native UI/provider behavior remains for human verification.

Required pending control state may exceed the configured history byte budget; individual items are wire-projected, and stream/HTTP snapshots report overflow. Arbitrarily capping the pending set would make some tasks unreachable by Stop again.

No merge was performed.