[BUG] VS Code extension: ScheduleWakeup/CronCreate stop being delivered to all sessions of a long-running extension host (silent, recovered only by full VS Code restart)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Symptom
A session running a self-paced loop (ScheduleWakeup, dynamic mode) received its wakeups every hour for ~1.5 days. From one point on (2026-10-07 ~05:00Z) no wakeup was ever delivered again to ANY session created in that extension host, for ~24 hours. ScheduleWakeup always returned "Next wakeup scheduled for HH:MM" and the extension log recorded [loop] dynamic wakeup scheduled: Ns — <reason>, but no prompt was ever enqueued (no queue-operation enqueue in the session .jsonl, no [loop] firing line in the log). Calling ScheduleWakeup({stop:true}) hours later still reported "1 pending wakeup(s) cancelled", so the wakeup was queued, just never fired. CronCreate jobs (every 2 minutes) also never fired in the same state. The host process was alive and healthy (bridge heartbeats every 10-20 s in the log, no errors, no event-loop stall). The PC did not sleep.

What did NOT fix it / was excluded by controlled tests

• new session in a new tab (fresh claude.exe under the same extension host): not delivered
• /clear: not a factor (fresh sessions failed too)
• extension 2.1.291 vs 2.1.292: failed on both
• Remote Control (remoteControlAtStartup true/false): not a factor
• hooks, settings, cached feature flags: unchanged across the working and failing periods
• same CLI from a terminal (2.1.293, TUI): wakeups delivered normally

Environment

• Windows 11 Pro 10.0.26300
• VS Code extension anthropic.claude-code 2.1.291 and 2.1.292 (bundled native binary, stream-json mode); CLI 2.1.293 (npm) in the terminal was NOT affected
• Sessions run from the Claude panel in VS Code, permission mode auto

What fixed it
A full VS Code restart (all windows closed, new extension host). After that, in the same kind of session: 60 s wakeup delivered on time, 600 s wakeup delivered at the exact scheduled second, CronCreate every-2-min job fired at its first window.

What Should Happen?

Expected
Either the wakeup fires, or the tool/host reports that scheduling is not possible. A silently stuck scheduler is the worst case for unattended loops: the session looks armed and nothing ever happens.

Error Messages/Logs

2026-10-08T03:23:31.643Z [INFO] [Stall] tool_dispatch_start tool=ScheduleWakeup permissionDecisionMs=334
2026-10-08T03:23:31.643Z [DEBUG] [loop] dynamic wakeup scheduled: 60s — diagnostic test wakeup
2026-10-08T03:23:31.643Z [INFO] [Stall] tool_dispatch_end tool=ScheduleWakeup outcome=ok durationMs=0
(session idle; scheduled time 03:25:00Z passes; nothing is logged and nothing is enqueued)
2026-10-08T03:26:13.946Z [DEBUG] [loop] model called ScheduleWakeup({stop:true}) — ending loop (1 pending wakeup(s) cancelled)

Session transcript (.jsonl): no "queue-operation" / "enqueue" entry between the two timestamps.
In the working state the same sequence shows the wakeup prompt enqueued within seconds of the scheduled minute.
No error, warning or exception is logged anywhere in between.

Steps to Reproduce

Not deterministically reproducible: observed after ~34 h of uptime of one VS Code extension host hosting several Claude panel sessions. In the broken state the following always fails:

1. Open a new Claude panel tab in the same VS Code window (fresh claude.exe, same extension host).
2. Ask the model to call ScheduleWakeup with delaySeconds=60 (no background task running) and end the turn.
3. Wait idle for 3 minutes: nothing is enqueued, no log line is written.
4. Call ScheduleWakeup({stop:true}): it reports "1 pending wakeup(s) cancelled".

After a full VS Code restart the same 4 steps deliver the wakeup within seconds of the scheduled minute.

Timeline (local time Europe/Rome, UTC+2)

• 2026-10-06 22:05 → 2026-10-07 07:01: wakeups delivered hourly (session A, host started 2026-10-06 20:41)
• 2026-10-07 07:37: session B (same host, /clear) arms a 3600 s wakeup → never delivered (still pending at 18:02 when cancelled)
• 2026-10-07 18:14 and 20:54, 2026-10-08 05:23: session C (same host, new process) arms 2760 s, 3600 s, 60 s → none delivered
• 2026-10-08 05:35: brand-new session, new tab, same host → 60 s wakeup not delivered
• 2026-10-08 07:03: full VS Code restart
• 2026-10-08 07:25 → 07:51: five wakeups (60-600 s) and one cron job delivered correctly

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

2.1.291 (the same version worked until 2026-10-07 ~05:00Z, then stopped: not a version regression)

Claude Code Version

2.1.292 (Claude Code) - VS Code extension bundled binary; also 2.1.291. npm CLI 2.1.293 in a terminal is NOT affected

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Second, separate behaviour (reproducible, probably by design but undocumented)
In the VS Code panel a wakeup is not delivered while a background task of the session (Bash run_in_background) is running; it is delivered a few seconds after the task-notification turn ends (deferred, not lost). In the terminal CLI the wakeup is delivered even while the background task runs. The ScheduleWakeup tool description does not mention this; tests that used a background "watchdog" timer were misleading for hours.

Logs
Extension logs (Claude VSCode.log) of the failing period were deleted by VS Code at restart; I kept the session .jsonl files and the extension logs after the restart. Happy to share them privately on request.