[BUG] Background Bash waiter completes but its notification never re-invokes the session; session idles until user input

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?

During an authorised long-running autonomous session, I started a Bash command with run_in_background: true acting as a waiter:

until tail -1 <logfile> | grep -qE 'run-gate exit='; do sleep 30; done

I then ended the assistant turn with that background task's completion notification as the only thing that could resume work.

The watched log line was written at ~23:45 local, so the loop's exit condition was satisfied and the command terminated. No notification re-invoked the session. The session sat idle from ~23:30 to 05:55 (6h25m) and resumed only on user input.

Background task IDs: br1ghbwl6 and bzuzeorji — two waiters on the same log file, neither of which woke the session.

This is a liveness failure rather than a correctness one: nothing was corrupted and no wrong action was taken. It matters because the value of an unattended run is that it can be left unattended. An intermittent silent stall means the session has to be checked on, which removes that value.

What Should Happen?

Completion of a background task delivers a notification that re-invokes the session, so work resumes without user input.

Error Messages/Logs

No error output. The command exited cleanly and the session simply was never re-invoked — the silence is the bug.

Steps to Reproduce

1. Start a long-running session.
2. Launch a Bash command with run_in_background: true containing a poll loop that exits when a line appears in a log file:

until tail -1 /tmp/gate.log | grep -qE 'run-gate exit='; do sleep 30; done

1. End the assistant turn with no other pending work, relying on that task's notification to resume.
2. From outside the session, append the awaited line:

echo "===== run-gate exit=1 =====" >> /tmp/gate.log

1. Wait past the 30s poll interval. Observe whether the session is re-invoked.

Expected: session wakes. Actual: session stays idle indefinitely.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

2.1.248

Claude Code Version

2.1.251

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

Model-side contributing factor (not a separate bug): the assistant treated a single background notification as a guaranteed wake path and scheduled no fallback heartbeat, despite operating under a standing "do not stop" instruction. A dropped notification therefore had no recovery path. Whatever the cause of the missed notification, relying on a single event for liveness is a weakness worth addressing alongside it.

Session context: turn 377/2091, 1 subagent active. Repository and log paths redacted (private project). API request IDs available on request.

Possibly related, not duplicates:

• #90534 — resume auto-fires armed background shells and /loop wakeups before any input (same subsystem, opposite direction)
• #90533 — scheduled-task registry silently rejected, all routines stop (relevant because ScheduleWakeup is the fallback path)