# Proof audit pass 1 — issue 23151

Issue: [#23151](https://github.com/pingdotgg/t3code/issues/23151), origin mirror [#23155](https://git.cafe/pingdotgg/t3code/issues/23155).

Audited complete diff: base [b5a226e49c](https://git.cafe/pingdotgg/t3code/commit/b5a226e49c52ecab4ddc2d678a7012d97e651a6a) → head [7b6753972c](https://git.cafe/pingdotgg/t3code/commit/7b6753972c700b3e4145716a88f134889a696f08), branch `fix/issue-23151`, checkout `/home/ubuntu/wt/issue-23151`. HEAD matched the requested head; worktree clean during audit.

## Complete diff inventory

Exactly two modified files, 56 insertions and 3 deletions:

- `apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts`: registration deadline changes from 90 to 690 seconds; explanatory comment changes. No other production behavior changes.
- `apps/server/src/orchestration-v2/Adapters/ClaudeAgentSdkQueryRunner.test.ts`: one regression test plus Deferred/Exit/Fiber/TestClock imports. The SDK registration promise is held until virtual time reaches 105 seconds; open must succeed and close must not be called.

## Render matrix

`[]` — zero changed render paths, render callers, visual conditions, or UI interactions.

No web, desktop, mobile, client-runtime, transport contract, generic error renderer, loading indicator, navigation entry point, command palette entry, or keybinding changes occur in the complete diff. Existing clients can observe a different outcome from the same server operation, but their render implementations are unchanged. Do not invent a frontend matrix for the unchanged generic provider-start error.

There are no affected render rows to mark as recording. If a supplemental demonstration uses the existing spinner, error, or retry interaction, label that demonstration **recording required; stills insufficient** because it conveys elapsed time/interaction. Such a UI demonstration is not required by the server-only proof procedure; timestamped runtime transcripts are required below.

## Affected backend path and conditions

- `openQuery` calls `ClaudeAgentSdkQueryRunner.open` when a Claude query must be created/replaced/resumed. It obtains MCP overrides from the thread's MCP session, passes them through `makeClaudeQueryOptions`, and registers them through the SDK control channel.
- The changed timeout wraps `setMcpServers` only when `mcpServers !== undefined`. This also includes an explicitly supplied empty map at the runner boundary. No configured MCP servers means no registration wait on this path.
- Existing compatible live-query reuse and continuation fast paths return the live query without calling open/registration again. A resumed session that actually creates a query still reaches open.
- Registration that finishes by 90 seconds should behave as before. A reply after 90 but before 690 seconds can now succeed. A never-answering registration now reaches the same timeout failure at 690 seconds rather than 90 seconds; its existing error cleanup remains unchanged.
- The deadline applies to all waits in this registration call, not only delays caused by startup hooks. Other providers are unchanged. Local/remote/tunnel clients all receive the result from this server-side operation; no origin-specific behavior was added.

## Minimal evidence handoff (not captured by this audit)

1. **Regression red/green transcript.** Run the added test unchanged against base production code (overlay only the head test), then head production code. Record the actual base/head full SHAs, `git status`, exact command, test name and exit status. Base must fail for the 90-second registration timeout/open failure, not compilation or environment setup; head must pass with no close call. Use the existing local `node_modules/.bin/vp`, narrowly selecting `ClaudeAgentSdkQueryRunner.test.ts` and `opens a session whose SessionStart hook outlasts 90 seconds`. Show the test overlay diff so the red run is not represented as pristine base. Do not claim these results from code inspection alone.
2. **Real cold-hook before/after runtime transcript.** Use isolated state and an isolated fixture with an actual Claude CLI `SessionStart` startup hook configured for a 600-second timeout and a controlled 105-second delay. Exercise T3's real Claude adapter with the MCP session configured, not only standalone `claude -p` and not the test's mocked SDK. Record hook start/end markers with timestamps, runtime start/end or failure timestamps, thread/session correlation, registration result, and final turn outcome. The base run must fail around 90 seconds with `setMcpServers` / `Claude Code did not answer the MCP server registration.` The head run must remain pending past 90 seconds, finish the hook around 105 seconds, register MCP successfully, and complete a small deterministic prompt. A base hook may be terminated before its end marker; show termination rather than inventing completion. Ensure each before/after run is independently cold: do not let the base run warm the head fixture.
3. **Controls in the same runtime evidence.** Confirm a main-checkout/no-delay start, a warm-worktree start (hook exits promptly), and a follow-up turn using the live query still succeed. Run comparable controls on base and head; distinguish the warm new-query case from reuse of a live query. Include registration completion for the new-query controls and no new startup hook for the live follow-up. This rules out a general provider/configuration failure and shows the fix does not impose a 690-second delay on fast starts.
4. **Actual revision markers.** For each runtime run, record the executable/source checkout, actual full commit SHA, effective deadline (90 or 690 seconds), CLI/SDK versions, and a sanitized fixture/hook configuration. Tie logs to the process executing that revision. A branch name or caption alone is insufficient; a head checkout with a stale base build is not after-proof. Any build preparation belongs to the later evidence-capture phase, not pass1. Remove authorization headers, pairing tokens and unrelated private data from shared evidence.

The 105-second regression proves the old cutoff is crossed; it does not independently prove real CLI hook ordering, a full ten-minute hook, arbitrary user-configured hook timeouts, or the exact 690-second boundary. Keep claims bounded. A virtual-clock boundary/control test may support the 690-second cap if that exact bound is claimed, but waiting 690 wall-clock seconds is not required for the minimal bug proof.

## Pass1 result

Render-proof classification: PASS, empty matrix is justified by the complete diff. Runtime/test proof: PENDING capture; no executions or pre-existing evidence were certified in this read-only audit. No code blocker found by this proof-scope inspection. The reported two independent MERGE reviews are input context, not reviews independently performed here.

No source edits, checkout changes, tests, rebuilds, servers, browsers, recordings, commits, pushes, or forge comments were performed. This matrix was written outside the worktree and uploaded with the ghdrop skill as requested.

FRICTION: none