# Issue 16636 runtime proof

AI-assisted; verified with the tests and tools listed above.

This proof runs the real T3 development server, real CLI, real Codex 0.167.2 app-server, and a Chromium web client. It does not use test doubles for the orchestration worker. The fifth thread uses T3's free recorded replay provider; its displayed tool/test results are replay content, not validation tests for this fix.

Both sides started with fresh databases (T3CODE_DEV_SEED=0), the same synthetic git project, a light theme, and a 1280 x 800 viewport. The recordings show the browser while drive.py creates the threads through the real CLI. The black rectangles redact a private environment label and a temporary workspace path. The stills crop the stable conversation area, excluding changing elapsed-time indicators. Each still's cropped pixels matched an earlier capture taken more than 500 ms before it.

Base: b68aedfdb71534bfdfbe55771ef2e686742faa8e
Head: 035787a31820f27708886d7feb66cbe45fa56c1b

1. Install dependencies in one checkout per commit with vp i.
2. Keep these scripts together in a scratch folder. Run `python3 prepare.py CHECKOUT before` (and `after` for the other checkout). Initialize and commit the generated synthetic workspace as a git repository.
3. Make proxy.cjs executable. If needed, set CODEX_REAL_BINARY to the installed real Codex executable. Start each checkout with `T3CODE_DEV_SEED=0 T3CODE_AUTO_BOOTSTRAP_PROJECT_FROM_CWD=0 HANG_LOG=SCRATCH/SIDE/dropped.jsonl vp run dev`.
4. Pair the browser using that server's startup pairing URL. Start the browser recording.
5. Set REPRO_MODEL to an available Codex model, then run `python3 drive.py CHECKOUT SIDE`. The model identifier is deliberately supplied by environment rather than published in this evidence. No request reaches inference: the proxy drops thread/start, turn/start and thread/resume without a reply, while forwarding everything else to the real app-server.
6. The driver starts four Codex threads, verifies that all four provider-turn.start rows are running and that the proxy dropped four requests, then starts Healthy replay thread using devReplay/showcase. Open that thread in the web client, expand Working, and hide the thread details panel.
7. Observe for 66 seconds after the fifth launch. The driver reads only this isolated database, using SQLite mode=ro. It logs the persisted effect status, attempt count, lease expiry, and assistant-message count once per second.

Observed base: Healthy replay thread remained pending, attempt count 0, with 0 assistant messages throughout 66.1 seconds. All four unanswered starts remained running at attempt count 1 with null lease expiry.

Observed head: the healthy thread produced its first assistant message 27 seconds after launch and its start succeeded at attempt count 1. It finished its replayed response. All four unanswered starts remained running at attempt count 1 with null lease expiry throughout the same 66.1-second observation window.

The fix releases worker slots after a 30-second wait; it does not terminate the unanswered provider effect. The transcript and recording establish cross-provider progress despite those effects staying unanswered. Same-provider recovery, other effect types, shutdown, late replies, and other clients were not separately exercised.