[BUG] /loop scheduled task stops firing on its own after the session is backgrounded — fires only right after a user turn

What's Wrong?

A /loop 3m <prompt> (CronCreate */3 * * * *, recurring) fired every 3 minutes in an interactive session (17 fires between 20:01Z and 20:54Z).

At 20:56:07Z the session was backgrounded ("Backgrounding after the current tool finishes…" → continued-in, new session id under the daemon, --fork-session --resume).

After that, the task still appeared in CronList, but it never fired on its own while idle. It fired exactly once after each user message turn ended (21:05:46Z, 22:27:15Z, 22:43:27Z, 22:46:47Z) and then went silent again. Gaps: 80 minutes (21:06Z → 22:26Z) and 15 minutes with no fire.

Deleting the task and recreating it with CronCreate inside the background session behaved exactly the same.

The background process stayed alive and attached the whole time (attach via agent view at 20:57:21Z), so this is not the "unattached for about an hour → supervisor stops the process" case.

What Should Happen?

Per https://code.claude.com/docs/en/scheduled-tasks (Limitations): "Backgrounding the session carries /loop tasks over to a background session, which keeps running without a terminal."
The task should keep firing every 3 minutes (within the documented jitter) in the background session without needing a user message.

Steps to Reproduce

1. Start claude interactively in Windows Terminal.
2. /loop 3m <some prompt> and let it fire a few times.
3. Session gets backgrounded (in our case without any key input — see separate report), then attach to it from agent view.
4. Send no further messages. Observe: no more fires.
5. Send any message: after that turn ends, the task fires once, then stops again.

Claude Code Version

2.1.281 (session started on 2.1.280)

Additional Information

Windows 11 Home (build 26200.9550), Windows Terminal 1.24, Korean IME. Claude Code native install; interactive session started on 2.1.280, native auto-update to 2.1.281 recorded at 2026-09-23T20:56:10Z (the same second the session was backgrounded).

Evidence (local): transcript scheduled_task_fire entries; ~/.claude/daemon/roster.json; ~/.claude/daemon.log (daemon start 20:56:10.543Z, bg spawned <id> (slash)).