fix(server): a Claude thread waiting on a ScheduleWakeup stays in Working#23648

Problem

When a Claude agent calls Claude Code's native ScheduleWakeup tool (for example in a self-paced /loop) and ends its turn, the thread leaves Working and lands in the inbox as if it were done, although Claude will start a new turn on its own when the delay ends. Repro on main (ed3f965e07): Working section on, new Claude Sonnet 5.5 thread, ask it to call ScheduleWakeup with delaySeconds: 120. The turn completes with pendingBackgroundTasks: [], the thread moves to the inbox, and about two minutes later Claude starts the wake turn by itself.

Change

The Claude adapter now records a pending wakeup from the ScheduleWakeup tool result (tool_use_result.scheduledFor). While it is pending, the provider thread publishes one extra background_task entry, "Scheduled wakeup", in pendingBackgroundTasks. Existing paths already treat that entry as waiting work: the thread stays in Working as "Waiting", the background-work banner shows it with Stop, auto-settle waits, and the idle session release keeps the Claude process alive (a wakeup can be up to an hour out, past the 30-minute idle timeout).

The record lives outside the adapter's background-task roster, so a pending wakeup does not refuse a model, mode or provider change. Such a change replaces the Claude process, which cancels the wakeup and clears the record.

The record clears when:

• the wakeup is cancelled (stop: true, which returns scheduledFor: 0) or the call fails;
• the wake turn starts (an idle system/init at or after scheduledFor - 120 s; Claude fires one-shot wakeups up to 60 s before the minute-rounded scheduledFor); a ScheduleWakeup inside that turn sets a new one;
• a host turn starts at or after scheduledFor;
• a turn is interrupted or cancelled, a turn fails because the process exited, or the process closes, is replaced, or is stopped.

The record stays through a user turn that starts before the wakeup, a failed turn whose process is still alive, and a background-task notification wake that arrives well before the wakeup.

Scope and approval

Fixes #20249

Triaged bug via the automated issue flow; the maintainer confirmed it on the issue.

Verification

Focused tests, vp test run apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.test.ts: 216 passed after merging main. New tests:

• a turn that scheduled a ScheduleWakeup and ended keeps holding completion: the reproduction, which failed on main with published pendingBackgroundTasks: []: expected false to be true.
• Wake turn clears the hold, on time and 30 s early; a wake turn that reschedules keeps it.
• stop:true releases the hold.
• Stop on a waiting thread closes Claude and drops the hold; hasPendingBackgroundWorkForThread stays false, so model and mode changes are not refused.
• A user turn before the wakeup keeps the hold.
• A failed turn with a live process keeps the hold.
• A background task waking Claude long before the wakeup keeps the hold.

apps/server typecheck: no errors.

Evidence

Real web dev app, live Claude Sonnet 5.5 runs. Before = ed3f965e07, after = 952d52ee2f (the fix before merging main). Environment for every capture: T3 preview browser (Chromium 154, headless, Linux x86_64), no emulation, DPR 2, viewport 1440×900 (stills saved at 1280×800), 390×844 for the narrow row. Both sides ran from one worktree and one seeded database. Prompt: "Use the ScheduleWakeup tool with delaySeconds 120 and prompt 'Reply with the word WOKE and nothing else.' Do not do anything else, then end your turn with one short sentence." Full page with every row and state read-out: evidence.md. Fixture matrix: matrix.md.

Turn ends with a wakeup pending (recordings, 1440, dark).

• Before (B0), UTC: 13:22:56 send → 13:23:05.3 turn completes with pendingBackgroundTasks: [] → the row stays in the inbox, with no Working section and no banner. B0-before-turn-end-1440-dark.mp4
• After (F1 → F3), UTC: 13:25:42 send → 13:25:48.9 turn completes with the claude-scheduled-wakeup entry → the row moves to "Working (1)" as "Waiting" and the banner reads "Waiting on background task Scheduled wakeup · Stop" → 13:28:00.98 the wake turn starts by itself → 13:28:04.57 it completes with pendingBackgroundTasks: [], "WOKE" renders, and the thread settles to the inbox. F1-F3-after-turn-end-wait-wake-1440-dark.mp4

Stills right after the turn ends. The before image is the same file in the dark F1 row and the F2 row; it was taken with the Working section on. On main the section only appears while a thread is running, so the same image also stands for the setting off.

Stop from the banner (F5, recording, 1440, dark). UTC: wakeup scheduled for 13:31:00 → 13:29:27.6 click Stop → 13:29:28.24 pendingBackgroundTasks: [], and the banner and Working section disappear → the last frame, at about 13:32:01.5 (scheduled time + 61 s), shows no wake turn. A read-out at 13:32:09 still lists only run 1. F5-after-stop-through-scheduled-plus-60s-1440-dark.mp4

Other rows (after only, 1440, dark):

• Wake reschedules, then finishes (F4): the hold stays between wakes and clears after the last one. F4 recording
• Agent cancels with stop: true in the same turn (F6): no hold, as on main. F6 recording
• User message while the wakeup is pending (F7): that turn settles back to Waiting, and the wake still fires. F7 recording
• 390×844, dark (F8): chat banner · sidebar Working section

What else changed in the pairs:

1. Intended: a "Working (1)" section with the row as "Waiting Ns" (section on), or "Waiting Ns" in place (section off), and the banner above the composer. With the section on, the inbox list shifts up.
2. Environment: the right panel shows a detached HEAD before and fix/issue-20249 after.
3. Environment: thread titles, agent text, durations and wake times differ between the live runs. Because both sides shared one database, the after sidebar also lists earlier test threads (the before thread, and in the light still the F1 thread). The light after still comes from the F5 thread.
4. Environment: in both F1 after stills, the sidebar's New-thread button is still highlighted from the click that opened the draft.
5. Existing Stop behaviour, shown in F5: Stop on a settled run with pending background work records an interrupt request on that run (Orchestrator.ts dispatchRunInterrupt). The timeline then stops folding that run, so its "Worked for 5.7s" header shows as the bare ScheduleWakeup tool row. Stopping a settled run with a running Monitor on main takes the same path. No client code changed here.

Not checked: mobile (thread list "Waiting", detail banner and background-work sheet). Agent device access is off on the verification host, and the static mobile fixture cannot seed pendingBackgroundTasks. No mobile code changed; mobile reads the same shared derivation that the web captures exercise.

Model and harness: Claude Opus 5.5 (lead, implementation, review) and Claude Sonnet 5.5 (review) in Claude Code, run from T3 Code.

🤖 Generated with Claude Code

Fixes pingdotgg/t3code#20249