[BUG] Bash sleep-block guidance prescribes the Monitor tool in sessions where the harness itself reports "Monitor is disabled for this session"

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?

Claude Code rejects Bash tool calls whose first statement is a bare sleep N with N ≥ ~25 before execution, with an error telling the model to use the Monitor tool instead (full text below). Reasonable feature — when Monitor is actually available.

But we caught one session contradicting itself, 37 minutes apart, both messages emitted by the harness:

• 10:17:23Z — the model ran sleep 90; gh pr view … and got:

Blocked: sleep 90 followed by: … To wait for a condition, use Monitor with an until-loop (e.g. \until <check>; do sleep 2; done\). …

• 10:54:53Z — the user asked the model to invoke Monitor once (command: echo monitor-probe), and the same session got:

Error: No such tool available: Monitor. Monitor is disabled for this session, in subagents as well as here.

So the primary remedy prescribed by one harness error message is a tool that the harness itself declares disabled for that very session. The model has to notice the contradiction on its own and improvise (here it fell back to a foreground until … done loop, which was accepted — after burning a turn, and after the user watched the harness instruct its own model to use a tool it had disabled).

Context that makes this look like an availability/rollout divergence rather than configuration:

• A concurrent session on the same machine — same Docker container, same CLI 2.1.235, same model (claude-fable-5), same settings.json (no permission deny involving Monitor), started the same way — had Monitor enabled and working (a call succeeded, events + completion delivered), and the same sleep block fired there as designed.
• Asked to enumerate its tools, the affected session was also missing ListAgents, Artifact, and EndConversation relative to the healthy one — i.e., a per-session availability decision, not a user setting. (#86171 documents one way Monitor can be absent — telemetry-related env vars — but those are not set in this environment, and the healthy concurrent session proves the environment as such supports Monitor.)
• A second session the same afternoon hit the same block (Blocked: sleep 25 … at 10:06:50Z) and likewise never used Monitor.

Frequency: in this one environment's transcript archive, the sleep block has fired in 82 distinct session/subagent transcripts between 2026-06-22 (v2.1.185) and 2026-08-19 (v2.1.235). 40+ other transcripts contain successful Monitor calls, so the block's advice is usually followable — the damage is concentrated in sessions where the prescribed tool is disabled.

What Should Happen?

An error message's prescribed remedy should exist in the session it's shown to:

• If Monitor is disabled for the session, the block message should not prescribe it — suggest run_in_background: true and/or a foreground until <check>; do sleep 2; done loop (both work today without Monitor), or don't block the command.
• Ideally, "the sleep block is active" and "Monitor is available" should be the same condition evaluated at the same point in time, so they cannot diverge within one session.

Error Messages/Logs

Blocked: sleep 90 followed by: gh pr view 8 --repo <org>/<repo> --json statusCheckRollup --jq '.statusCheckRollup[] | [.name // .context, .status // .state, .conclusion // ""] | @tsv'. To wait for a condition, use Monitor with an until-loop (e.g. `until <check>; do sleep 2; done`). To wait for a command you started, use run_in_background: true. Do not chain shorter sleeps to work around this block.

Variant when the command is a lone sleep:

Blocked: standalone sleep 25. To wait for a condition, use Monitor with an until-loop (e.g. `until <check>; do sleep 2; done`). To wait for a command you started, use run_in_background: true. Do not chain shorter sleeps to work around this block.

Same session, 37 minutes after the first message above, on an explicit Monitor invocation:

Error: No such tool available: Monitor. Monitor is disabled for this session, in subagents as well as here.

Steps to Reproduce

Which sessions get Monitor disabled is not externally controllable as far as we can tell (identical concurrent sessions diverge), so this is the observed shape rather than a deterministic recipe:

1. Find a session where Monitor is disabled: ask the model to invoke Monitor once — the affected state answers No such tool available: Monitor. Monitor is disabled for this session, in subagents as well as here.
2. In that session, run a Bash command starting with a long bare sleep, e.g. sleep 25; echo hi.
3. The call is rejected with guidance whose primary prescription is the tool from step 1.

Behavior of the block itself (all verified first-hand on 2.1.235 / Linux, in the session where Monitor was enabled):

• sleep 24 && cmd executes; sleep 25; cmd and sleep 90; cmd are blocked → threshold ≈ 25 seconds
• Only the first statement counts: cmd; sleep 300; cmd, for i in …; do sleep 45; …; done, until <check>; do sleep 15; done all execute
• sleep 15; sleep 15; cmd executes (leading sleeps are not summed)
• run_in_background: true bypasses the block, as the message promises

Related issues

• #86171 — Monitor silently unavailable when DISABLE_TELEMETRY / CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC is set (a documented way the tool can be absent; not our env)
• #86085 — the same block guidance is unsafe advice when it fires inside a subagent
• #76239 — precedent for this class: tool availability decided in a startup race (MCP tools silently missing) while other code paths assume presence

Claude Model

Other: claude-fable-5 (both the affected and the healthy session)

Is this a regression?

Not sure

Claude Code Version

2.1.235 (the block itself observed in our transcripts from 2.1.185 through 2.1.235)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux (Docker container, arm64; ANTHROPIC_BASE_URL points at a local proxy; telemetry-disabling env vars are not set)

Terminal/Shell

iTerm2

Additional Information

Unverified hypothesis, offered in case it helps: per-session tool availability looks frozen near session startup, while the sleep block's activation appears to be evaluated per call — under that shape the two can disagree for a session's whole lifetime, which matches what we saw (the affected session kept its "disabled" answer while the block kept firing). Happy to provide more environment details on request.

The block message's own fallback advice is sound — foreground until loops and run_in_background both work without Monitor — so the smallest fix is making the message availability-aware.

✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)