fix(server): threads stay working while Claude starts a wake turn

[t3dotgg]

Problem

A Claude thread that waits on a background command leaves "working", drops back into the inbox for a few seconds, then returns to "working" when Claude reacts to the finished command.

The adapter started the wake run only at the wake turn's first assistant/user frame. Claude thinks before that frame. In the local provider logs, init to first output took 3 to 49 s (often 5 to 30 s). During that time the roster was already empty and no run existed, so the thread looked done.

From the reported thread (8092e030):

05:38:29.230  task_notification   background command done, roster clears
05:38:29.293  system/init         Claude starts the wake turn
05:38:33.088  first assistant     wake run created (05:38:33.131)

#15029 stops the timer reset on wakes, but not this status gap.

Change

Claude opens every turn with a root system/init frame. With no T3 turn active, that turn is a wake. In 28 out of 28 idle notifications in the local logs, init came 21 to 108 ms after the notification.

• bufferWakeMessage buffers that init and offers the wake continuation on it.
• The continuation drain counts a buffered init as a native wake frame. The run stays open for the live output and does not settle at once.

The gate for a notification alone is unchanged: with no init, no run starts.

This also covers a background task that ends while a turn is still running. In that case the wake turn has no buffered notification, and before this change it got a run only at its own result.

Claude only. The other adapters detect wakes in their own way.

Scope and approval

Small, focused fix of a bug Theo reported.

Verification

• New test starts the wake run when Claude opens the wake turn, before its output. It fails on main (no continuation request after init). It also fails when only the drain change is reverted (the run settles before the output).
• ClaudeAdapterV2.test.ts, ClaudeReplayFixtures.integration.test.ts, ProviderContinuationService.test.ts, runtimeLayer.test.ts: 204 tests pass. The Orchestrator replay fixture suites pass (129).
• apps/server typecheck is clean.

Not checked: a live run in the desktop app. The roster still clears about 60 to 150 ms before the new run appears, so a very short blink can remain.

Created with Claude Opus 5.5 in Claude Code (T3 Code).

🤖 Generated with Claude Code

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

🧰 Additional context used

📚 Code guidelines (1)

docs/internals/effect-services.md — configured

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Repository: pingdotgg/t3code/.coderabbit.yaml
• Review profile: CHILL
• Plan: Team
• Run ID: 979396a0-21c1-4429-863c-dd7d04310b17

📥 Commits

Reviewing files that changed from the base of the PR and between d1034d6 and b46ff07.

📒 Files selected for processing (2)

• apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.test.ts
• apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 2 remain after this review.

---

📝 Walkthrough

Walkthrough

ClaudeAdapterV2 now recognizes a root init frame as wake-turn evidence and as native wake output during buffered drains. A lifecycle test checks when a continuation is offered and when it completes.

Changes

Claude wake-turn handling

Layer / File(s)	Summary
Recognize init frames during wake handling apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts, apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.test.ts	Wake detection and buffered-drain handling now include root init frames. The test verifies that the notification alone does not offer a continuation, that the init frame does, and that the run waits for assistant and result frames before completing.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Suggested reviewers: juliusmarminge

Merge Risk: ⚪ Minimal · up to b46ff

No actionable issue is established for the Claude wake-turn change; it is ready to merge after normal checks.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 25.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 4 functions across 2 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the fix: keeping threads working while Claude starts a wake turn.
Description check	✅ Passed	The description covers the problem, change, scope and approval rationale, and verification. It also states the live desktop-app check was not performed and notes the remaining status gap.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

• Fix all pre-merge checks with AI

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Approved at b46ff07

Macroscope's review found this PR approvable — This is a focused Claude wake-status fix with a targeted regression test and no schema, default, infrastructure, or sensitive-path changes. An unresolved High finding identifies a normal-turn init race that can create a phantom continuation, so that correctness risk remains a blocker to merging.

Notes:

• This verdict was updated automatically after the outstanding correctness findings were resolved. Macroscope did not re-review the code.

^{You can add or adjust custom eligibility rules. Learn more.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	4.9 KiB	4.9 KiB	0 B (0.0%)	6.8 KiB	✅
Codex	Thread snapshot wire	3.7 KiB	3.7 KiB	0 B (0.0%)	4.9 KiB	✅
Codex	Live turn WebSocket wire	1.2 KiB	1.2 KiB	0 B (0.0%)	2.0 KiB	✅
Codex	Live turn WebSocket decoded	20.4 KiB	20.4 KiB	0 B (0.0%)	29.3 KiB	✅
Codex	Live turn messages	2	2	0 (0.0%)	8	✅
Claude	Total thread wire	4.9 KiB	4.9 KiB	0 B (0.0%)	6.8 KiB	✅
Claude	Thread snapshot wire	3.7 KiB	3.7 KiB	0 B (0.0%)	4.9 KiB	✅
Claude	Live turn WebSocket wire	1.2 KiB	1.2 KiB	0 B (0.0%)	2.0 KiB	✅
Claude	Live turn WebSocket decoded	20.8 KiB	20.8 KiB	0 B (0.0%)	29.3 KiB	✅
Claude	Live turn messages	2	2	0 (0.0%)	8	✅

Baseline: d1034d6 · PR result: b46ff07 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 106.1 KiB
• Claude decoded thread snapshot: 106.4 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.