Claude wake latch: a wake queued behind a held run swallows later wakes, so idle-launched subagents stay Running#22033

Thanks for the deterministic replay. The guard does what you describe on current main. When a task_notification arrives while the root is idle, the outcome is applied directly only if no task_started for that task is still in the wake buffer, or if a stop outcome is already known (apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts:7112-7125). Otherwise it waits for the continuation drain. #18778 added that deferral so an old buffered start replaying later couldn't flip a finished subagent back to running.

The replay depends on step 2, though: it leaves the idle launch's continuation undrained. A subagent task_started that arrives while the root is idle is buffered specifically so that a continuation drains it (lines 6669-6675). In the normal flow that drain processes both the start and the later notification and settles the task. So the open question is what kept that start undrained in your real incident. A held or jammed continuation would make this the same root cause as #20430, or the wake that never opens in #19196, rather than a separate problem with the guard.

To narrow it down, could you check the provider log and run history from the production incident:

1. Did a continuation or wake run start between the idle task_started and your next user turn?
2. Was any queued or held run sitting on the thread at that point?
3. Did any run start after the final task_notification arrived?

I checked the production run/event history and reproduced this with a fresh native Claude Agent task on the installed macOS nightly 0.1.1-nightly.20261018.3331.

Fresh synthetic probe, relative to its idle launch:

There was no T3 continuation/wake run between the idle start and that later message turn, and no queued or held run was found in the durable history. The probe used sequential foreground echo calls, with no SendMessage resume, own background shell work, or interim completion notification. Its last persisted update precedes the final notification by about 68 seconds.

For the three original agents:

1. Two launched while idle. Neither had a continuation run before the later turn that discovered it. No queued or held run was found. Both had later T3 runs after their final notifications, and those did not repair their status.
2. The third launched during an active turn, then had an idle resume/start between turns. Progress during the next T3 turn was recorded; its final idle notification was not. Later T3 runs did not repair it either.
3. One of the two idle launches had no resumes and no interim notifications, so neither is necessary for this failure.

The store does not expose the adapter's in-memory requestedContinuations set, so I cannot rule out a stuck latch solely from that history. I can confirm that the native Claude wake activity itself occurred without a corresponding T3 run.

I agree that removing the guard is wrong: that candidate broke the existing genuine-resume regression and was rejected. The revised candidate keeps the guard and consumes the matching buffered plain-agent start through normal registration before later live progress creates a fallback entry. The ordered adapter replay, real SQLite persistence case, and existing genuine-resume case pass. The broader focused run has 304 passes and one unchanged steer-test timeout, now being checked against baseline. Independent review is running; I will link the patch and installed after-evidence when verified.

The fix is offered in #22049 (through 1e0716cadf). Native fork artifacts are published in preview 20261020.2, commit 2ef9c7940e14.

The single replay runner runs the same idle-start regression on two prepared worktrees. Apply the test-only patch in this issue to the baseline worktree, install dependencies in both, and run:

It temporarily selects the installed nightly adapter source in the baseline worktree and restores it in finally. Observed before: exit 1, expected 'running' to equal 'completed'. Observed after: exit 0, the same test passes. This is SDK replay evidence, not a live provider test.

Separately, a native synthetic after-probe on the initial installed preview exercised idle self-resume → later-turn discovery → final idle completion:

The old nightly's native probe instead remained running with completed_at null after its final notification. The after-probe used an idle self-resume because notification-woken turns now opened T3 runs after restart; the reason for that wake difference is unproven. Historical stale rows were separately cancelled by normal startup recovery, not retroactively confirmed completed.

The follow-up also covers both active-turn pending frames and idle wake-buffer child frames. Its regression proves idle/live output order, tool completion before the terminal update, sibling isolation and no duplicate output on a later continuation drain. 53 focused checks, server typecheck and native Windows/macOS package validation pass. Independent review found no material defects. The unrelated early interim-completion behavior (#16610) remains.

You were right to ask about held runs. Our earlier answer to (2) only looked at runs 14 to 28, and it was wrong. I've now reproduced the whole route on current main through the app, with no injected frames.

Repro on main 3b95e7831b, Windows, web dev client, Claude Sonnet 5.5

Every message after the first Stop goes through the MCP / t3 thread send path, so none of them is a client message that would release the hold (#21473).

1. Start a long turn, for example 60 sequential echo calls. While it runs, send a follow-up so it queues. Press Stop in the composer. Run 1 is interrupted and the queued run 2 becomes queued, queueHeld: true.
2. Send (via t3 thread send): start node -e "setTimeout(()=>{},30000)" with run_in_background: true, then run a 26 s foreground node -e "setTimeout(()=>{},26000)", then write a ~300-word reply and end the turn. When the background command's notification arrives, call Agent with run_in_background: true (60 sequential echo probe3-step-n calls), then end that turn. The point of the timing is that the background command finishes while the run is still settling.
3. About 50 s after the launch, send a one-word ping via t3 thread send.
4. Wait for the agent to finish.

Two controls from the same thread:

• With the queue held but no run active, a background wake opened continuation run 5 immediately. The Agent launched inside it, and it completed normally. A hold alone doesn't jam anything. The wake has to be dispatched while a run is active, so that it queues and inherits the hold.
• When the background command finished mid-turn, Claude handled the notification inside the tracked run, and that agent completed normally.

The original incident, on 0.1.1-nightly.20261018.3331

The same shape occurred in normal use.

1. 13:12:32Z: the thread's runtime mode was changed during an active turn. thread.runtime-mode.set detached the session, run 1 failed, and the already queued run 2 (a delegated-task wake) became queueHeld: true.
2. Run 8 and run 12 were later created held. Run 12 was the Claude background-task continuation at 13:43:02Z, dispatched 4 s after run 11 completed, at queuePosition: 4. None of them started.
3. From 13:43Z until the next restart at 00:54Z, no native wake on the thread opened a T3 run. All three stale agents were launched in those untracked native turns:
   • the probe: launched in a turn woken by an earlier probe's notification;
   • one original agent: launched in a turn woken by a background Bash command that finished 12.5 s after its run ended;
   • the other original agent: launched in a turn woken by a Stop hook.
4. Later human messages did not release the hold, because #21473 is not in 3331. After the restart, the next background wake opened a run immediately.

Conclusion

The stale row follows from the open latch half of #20430. The held continuation keeps requestedContinuations set, so later wake turns, and the Agent launches inside them, never get a run. The start stays buffered, and the final notification waits behind it. Theo asked on #20430 for a separate issue covering only the latch, so I've retitled this one to it. With the latch fixed, wake turns would drain the start normally. #22049 then only matters if a start can be stranded some other way, and we're fine closing it if you'd rather not carry it as defense in depth.

Follow-up: I reran the same route against both open fixes, on main 3b95e7831b with the same Stop, MCP-only messages and timing as above.

#22049 alone does not cover it. The wake continuation (run 4) was again created queued, queueHeld: true while run 3 was settling, and never started. The Agent launched in the untracked wake turn at 07:51:50Z. The later ping (run 5, 07:52:54 to 07:53:00Z) happened to fall between two of the agent's task_progress frames (07:52:53.8Z and 07:53:00.2Z), so the buffered-start replay never fired. The agent finished at 07:55:29Z with the parent idle, and T3 never recorded it at all: no subagent row, run 4 still held. #22049 only helps when a progress frame happens to land inside some later run.

#17885 does cover it. With its Orchestrator and ProjectionStore changes applied on the same base (only conflict was the Codex test assertion, since that test is gone on main):

Focused suites pass on that build: runtimeLayer, ProjectionStore, ThreadLaunchService, BackgroundWorkStop, ThreadStop and CodexAdapterV2 (286 tests). That build also carried #22049, but it wasn't exercised: the start arrived inside run 4.

So for this route the fix is #17885, which needs a rebase onto main. What it leaves open, by its own description, is a wake dispatched after Stop reaches the active run: that one is still held, and the latch stays set until the CLI restarts. #17109's release-on-cancel/fail would close that. I'm happy to close #22049 in favour of #17885.