[BUG] Scheduled-task session is paused by CliGovernor right as a background task's completion notification arrives; the wake-up is lost and the run stalls

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?

Environment

• Claude desktop app (macOS, arm64, 18 GB RAM), Code tab, local scheduled task ("routine")
• 2026-10-02: app 2.16120.0, embedded Claude Code 2.1.284
• 2026-10-03: app 2.19675.0, embedded Claude Code 2.1.286

What happened
A scheduled task launches a long command with the Bash tool's run_in_background: true,
ends its turn, and relies on the completion notification to start the next turn.
On two consecutive days the session was paused by the governor 2-3 seconds after the
notification was written to the transcript. No model response followed. The run stayed
stalled for hours until I typed a message into the session.

Timeline (local time, from ~/Library/Logs/Claude/main.log and the session transcript)
2026-10-03, session local_937423cf-c0db-4842-85d8-3e726d4c8e79
09:10:42 turn ends, one background Bash task pending
09:19:00 <task-notification> enqueued, dequeued, recorded as a user message
09:19:02 [CliGovernor] pressure evicting local_937423cf-... (idle 499s)
09:19:02 [CCD] Pausing session local_937423cf-... (governor_evict)
09:19:02 [CliGovernor] memory pressure (warning): evicted 1 of 1 idle session(s), 5 effective
09:19:09 [CCD] CLI process group 2243: nothing left
14:42:48 session reopened; transcript gets a synthetic "No response requested."
(model "<synthetic>", zero usage); the task does not continue
14:43:04 I type "continue"; the run resumes normally

2026-10-02, session local_f0db89e9-d769-4389-a5b8-a711ec2f58ab: same sequence
09:18:58 notification recorded
09:19:01 pressure evicting ... (idle 503s) -> Pausing session (governor_evict)
09:19:08 CLI process group 39123: nothing left
10:30:54 resumed only after I typed into the session

Expected
A session that has just been woken by a completion notification should not be treated
as idle. If it is paused anyway, the pending notification should be replayed when the
session resumes, so the task continues without a human.

Actual
The governor still reports the session as idle (idle time counted from the previous
turn's end) and pauses it. The notification is already consumed in the transcript, so
nothing re-triggers the turn. Reopening the session only adds "No response requested."

Why I think it is a race (partly inferred)
While the background task is running, the session is protected: the log shows
"Skipping pause for session ... - N active background task(s)" for the same pattern in
another run. That protection ends when the task completes. In the two failing runs the
pause landed in the short window after completion and before the notification-driven
turn was treated as running. I have not confirmed the exact ordering, and I cannot
explain why the pressure sweep landed within 2-3 seconds of the notification both days.

The same exposure applies to background subagents: a session that ends its turn waiting
for Agent-tool completion notifications is in the same idle-with-pending-work state.

Impact
Unattended scheduled tasks that wait on background Bash tasks or background subagents
can stall silently whenever the machine is under memory pressure and more than about
four sessions are live. There is no error, and the task run still shows as "running".

What Should Happen?

A session that has just been woken by a background task's completion notification
should not be treated as idle and paused by the governor.

If the session is paused anyway, the notification should not be lost: when the
session resumes, the pending notification should be delivered again so the task
continues without a human typing into it.

A scheduled-task run that has been paused mid-run should also not keep showing
as "running".

Error Messages/Logs

# Source: ~/Library/Logs/Claude/main.log (local time, UTC+8). Lines are verbatim
# except the project path, replaced with <project>.

# --- 2026-10-02 (app 2.16120.0, Claude Code 2.1.284) ---
2026-10-02 09:09:16 [CliGovernor] memory pressure (warning): evicted 0 of 0 idle session(s), 19 effective
2026-10-02 09:09:38 Starting local session local_f0db89e9-d769-4389-a5b8-a711ec2f58ab in <project>
2026-10-02 09:10:38 [Stop hook] Query completed for session local_f0db89e9-d769-4389-a5b8-a711ec2f58ab
2026-10-02 09:10:38 [WarmLifecycle:session] Starting idle timeout for local_f0db89e9-d769-4389-a5b8-a711ec2f58ab: 900s
2026-10-02 09:18:58 Mapping internal session local_f0db89e9-d769-4389-a5b8-a711ec2f58ab to CLI session 28de88ca-060e-4a0e-86e5-e3614b85be06
2026-10-02 09:19:01 [CliGovernor] pressure evicting local_f0db89e9-d769-4389-a5b8-a711ec2f58ab (idle 503s)
2026-10-02 09:19:01 [CCD] Pausing session local_f0db89e9-d769-4389-a5b8-a711ec2f58ab (governor_evict)
2026-10-02 09:19:01 [CliGovernor] memory pressure (warning): evicted 1 of 17 idle session(s), 21 effective
2026-10-02 09:19:03 Session local_f0db89e9-d769-4389-a5b8-a711ec2f58ab query iterator completed
2026-10-02 09:19:08 [CCD] CLI process group 39123: nothing left
2026-10-02 10:30:52 Resuming session local_f0db89e9-d769-4389-a5b8-a711ec2f58ab in <project>   <- only after I typed a message

# --- 2026-10-03 (app 2.19675.0, Claude Code 2.1.286) ---
2026-10-03 09:09:38 Starting local session local_937423cf-c0db-4842-85d8-3e726d4c8e79 in <project>
2026-10-03 09:10:42 [Stop hook] Query completed for session local_937423cf-c0db-4842-85d8-3e726d4c8e79
2026-10-03 09:10:42 [WarmLifecycle:session] Starting idle timeout for local_937423cf-c0db-4842-85d8-3e726d4c8e79: 900s
2026-10-03 09:19:00 Mapping internal session local_937423cf-c0db-4842-85d8-3e726d4c8e79 to CLI session 48413275-598a-43dd-8ec7-0bae7e188403
2026-10-03 09:19:02 [CliGovernor] pressure evicting local_937423cf-c0db-4842-85d8-3e726d4c8e79 (idle 499s)
2026-10-03 09:19:02 [CCD] Pausing session local_937423cf-c0db-4842-85d8-3e726d4c8e79 (governor_evict)
2026-10-03 09:19:02 [CliGovernor] memory pressure (warning): evicted 1 of 1 idle session(s), 5 effective
2026-10-03 09:19:04 Session local_937423cf-c0db-4842-85d8-3e726d4c8e79 query iterator completed
2026-10-03 09:19:09 [CCD] CLI process group 2243: nothing left
2026-10-03 14:42:47 [CCD] Warming session local_937423cf-c0db-4842-85d8-3e726d4c8e79   <- reopening alone did not continue the run
2026-10-03 14:43:04 Sending message to session local_937423cf-c0db-4842-85d8-3e726d4c8e79      <- continued only after I typed

# --- Session transcript (same two runs) ---
# 2026-10-02 09:18:58 and 2026-10-03 09:19:00: the background task's <task-notification>
#   is enqueued, dequeued and recorded as a user message (exit code 0).
# No assistant record follows until the session is resumed. The next record is
#   "No response requested." with model "<synthetic>" and zero token usage.

Steps to Reproduce

1. On macOS, have the Claude desktop app under memory pressure (level "warning")

with more than 4 live Code sessions.

1. Create a local scheduled task whose prompt starts a long command with the Bash

tool's run_in_background: true (mine runs about 8.5 minutes), then ends its turn
and waits for the completion notification.

1. Let the scheduled task fire unattended.
2. When the background command finishes, the <task-notification> is written to the

transcript, and 2-3 seconds later main.log shows:
[CliGovernor] pressure evicting <session> (idle ~500s)
[CCD] Pausing session <session> (governor_evict)
[CCD] CLI process group <pid>: nothing left

1. No model response follows. The run stays stalled until a message is typed into

the session.

Observed on two consecutive days (2026-10-02 and 2026-10-03) at the same step.
I have not tried to reproduce it on demand; it depends on memory pressure being
present at the moment the background task completes.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.286（10-03）；10-02 是 2.1.284

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_