Sign up
View stargazersSign up

[Bug]: A Claude thread waiting on a ScheduleWakeup timer leaves Working and lands in the inbox#20249

opened26d agobyRrolandorojas

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

packages/contracts or packages/shared

Steps to reproduce

  1. Turn on the Working section beta.
  2. In a Claude thread, start a self-paced loop (/loop with no interval) or ask the agent to check something again later. The agent calls Claude Code's ScheduleWakeup tool, for example with delaySeconds: 1200, and ends its turn.
  3. Look at the sidebar while the agent waits for the wakeup.

Expected behavior

The thread stays in Working until the wakeup fires and the agent finishes. The agent has not stopped. Claude Code will start a new turn in the same thread when the delay ends, and nothing needs the user before then.

Actual behavior

The thread leaves Working as soon as the turn ends and goes to the inbox (the ready list) as if it were done. When the wakeup fires, the agent starts a new turn and the thread moves back.

Cause (from reading main @ cfafb4bb54)

A pending wakeup is not recorded anywhere. ScheduleWakeup does not create an entry in pendingBackgroundTasks. The only kinds are command, subagent, monitor and background_task (packages/shared/src/orchestrationV2PendingBackgroundWork.ts). With nothing on the roster, the thread looks idle once its run completes. A code search for ScheduleWakeup and CronCreate finds no handling outside test fixtures.

This is a separate case from background commands. #15099 and discussion #15433 cover a thread that waits on a run_in_background command. That case is hard because a command can also be a dev server the agent walked away from. A wakeup has no such ambiguity: the agent always intends to come back.

Impact

Minor bug or occasional failure

Version or commit

0.0.46-nightly.20261015.3176

Environment

Linux x64 server, Claude provider (Claude Code harness, Opus 5.5)

Workaround

None in the UI. A long /loop thread sits in the inbox between every iteration.

JJulius Marminge26d ago

Note

Grok responding on behalf of Julius.

Confirmed on main: a pending ScheduleWakeup isn't tracked, so the thread settles when the turn ends.

backgroundWorkKindHoldsCompletion only holds a thread for subagent, monitor and background_task entries in pendingBackgroundTasks. A code search finds ScheduleWakeup only in a test fixture, so nothing adds a roster entry for a scheduled wakeup. Once the run completes, the thread looks idle and leaves Working.

This is separate from the background-command decision in #14910 (closed as intended in #18966; still open in #15099 and #17625). Commands were excluded because they're often long-lived processes the agent has walked away from. A wakeup is always meant to bring the agent back, so that reasoning doesn't apply here.

Keeping this open as a bug for the Working section beta.

JJulius Marminge20d ago

Reproduced on Linux x64, web dev app at 70e5e384da, Claude Code 2.1.303 / Opus 5.5, Working section enabled.

Asked Claude to check the time again using ScheduleWakeup with delaySeconds: 120. The tool returned scheduledFor: 1792622520000 (22:42 UTC). The turn completed at 22:39:07 UTC and the thread moved from Working to the inbox. A self-paced /loop with a 60-second wakeup reproduced the same transition.

Runtime transcript · Loop recording. The dev server disconnected later, so this run does not verify the return when the wakeup fires.

Before turn completion: Thread in Working

After turn completion, wakeup still pending: Thread in inbox while waiting

JJulius Marminge20d ago

Reproduced on Linux web at 70e5e384da, with Claude Code 2.1.303 and Opus 5.5, using both a direct ScheduleWakeup request and a self-paced /loop: the turn ended and the waiting thread moved from Working to the inbox.

The proposed roster-based fix also changes when model, runtime/permission mode, and provider changes are refused. Both independent reviews require a maintainer decision on that behavior. The local draft also needs cancellation handling for ScheduleWakeup({stop:true}) returning scheduledFor: 0, plus banner wording cleanup. No PR opened; leaving this issue open for Julius.

JJulius Marminge20d ago

Reproduced on Linux x64 in the web dev app at 8acbefefc5, Claude Code 2.1.303 / Opus 5.5, Working section enabled.

A direct ScheduleWakeup({delaySeconds:120}) returned scheduledFor:1792633020000 (01:37 UTC). At 01:34:58 UTC the turn completed with pendingBackgroundTasks:[], and the thread left Working for the inbox. A self-paced /loop with a 60-second native wakeup did the same at 01:35:48 UTC, before its 01:37 UTC wakeup.

Runtime transcript · Loop recording.