[BUG] ScheduleWakeup never fires in Remote Control child sessions (sdk-cli bridge) even though the session stays alive and task notifications are delivered

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?

In a Remote Control child session (official claude remote-control feature; the child session runs with CLAUDE_CODE_ENTRYPOINT=sdk-cli, CLAUDE_CODE_ENVIRONMENT_KIND=bridge, CLAUDE_CODE_CHILD_SESSION=1), ScheduleWakeup is accepted and returns its normal confirmation ("Next wakeup scheduled for HH:MM:SS (in Ns)"), but the wakeup never fires.

This is distinct from #74685 (--print exits at end of turn, so nothing can fire): here the session stays alive and the async re-invocation infrastructure demonstrably works — background task completion notifications (Bash with run_in_background) are delivered reliably and re-invoke the model every time. Only the ScheduleWakeup timer path is dead.

Observed over one unattended /loop session (dynamic mode): 7/7 ScheduleWakeup reservations never fired (delays ranging 60s–1250s). Every actual wake-up during the session came from a task notification or a user message. The loop silently stalled whenever it was waiting on a wakeup alone; a human happened to notice and ping the session, otherwise it would have slept forever.

Controlled experiment

Armed both timers in the same turn:

• 14:14:53 UTC — started background control task sleep 90 (run_in_background)
• 14:14:54 UTC — called ScheduleWakeup(delaySeconds=60); tool returned "Next wakeup scheduled for 14:16:00 (in 61s)"
• 14:16:00 UTC — wakeup deadline: did not fire (no turn occurred)
• 14:16:23 UTC — control sleep 90 exited; its task notification was delivered and re-invoked the model within seconds

Same session, same minute: notification path works, wakeup path doesn't.

What Should Happen?

The wakeup fires at the scheduled time and re-invokes the model with the provided prompt, as it does in interactive sessions — or, if Remote Control child sessions cannot support wakeups, the tool call should fail loudly instead of returning a success confirmation. The silent no-op breaks /loop dynamic mode: the skill's contract assumes the fallback heartbeat is real.

Error Messages/Logs

No errors. Tool result on every call:

Next wakeup scheduled for 14:16:00 (in 61s). Nothing more to do this turn — the harness re-invokes you when the wakeup fires or a task-notification arrives.

Steps to Reproduce

1. Start a session via the official Remote Control feature (child session env: CLAUDE_CODE_ENTRYPOINT=sdk-cli, CLAUDE_CODE_ENVIRONMENT_KIND=bridge, CLAUDE_CODE_CHILD_SESSION=1).
2. Run /loop <some prompt> (dynamic mode) or have the model call ScheduleWakeup with a short delay.
3. Optionally start sleep 90 as a background Bash task in the same turn as a control.
4. Wait past the wakeup deadline: the wakeup never fires; the background-task notification (control) arrives normally.

Claude Model

claude-fable-5

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.226 (exec path shows 2.1.225)

Platform

Anthropic API

Operating System

Linux

Terminal/Shell

Remote Control child session (sdk-cli bridge, non-interactive)

Additional Information

Possibly related: #74685 (--print/headless silent no-op — different lifecycle: that process exits, this session persists), #80679 (one-shot wakeups silently vanish), #82633 (scheduled outside /loop, never fires), #86245 (tengu_kairos_loop_dynamic flag gating — if wakeup firing is feature-flag-gated, the Remote Control bridge path may simply not be wired to the flag/scheduler).

Workaround that works today: end the turn with a background sleep N task instead of relying on ScheduleWakeup; its completion notification reliably re-invokes the model.