claude-code - 💡(How to fix) Fix Bash: sleep ≥2s blocked unconditionally, breaking legitimate polling/heartbeat patterns [2 comments, 3 participants]

Summary

The harness blocks any sleep N command where N ≥ 2 seconds, even when the sleep is a deliberate, intentional delay (e.g. heartbeat/poll loops). This makes it impossible to implement backoff-based polling within a single agent run.

Current behavior

Running: ```bash sleep 30 && echo "heartbeat" ```

Results in:

Blocked: sleep 30 followed by: echo "heartbeat". Run blocking commands in the background with run_in_background: true — you'll get a completion notification when done. For streaming events (watching logs, polling APIs), use the Monitor tool. If you genuinely need a delay (rate limiting, deliberate pacing), keep it under 2 seconds.

Expected behavior

sleep N should be allowed when the agent has a clear reason to wait (rate limiting, deliberate pacing between API calls, heartbeat polling). The block message itself acknowledges this: "If you genuinely need a delay (rate limiting, deliberate pacing), keep it under 2 seconds" — but 2 seconds is far too short for any real polling use case.

Concrete use case

I have a scheduled agent that:

1. Sends replies to a chat group
2. Needs to wait 30s, then poll again to catch follow-up messages (exponential backoff: 30s → 1m → 2m → 3m → 4m)
3. Exits after 5 consecutive empty polls (~10 min total)

This is a textbook heartbeat pattern. The run_in_background workaround doesn't compose well here because each heartbeat step depends on the result of the previous poll — it's not a fire-and-forget.

Workaround

Currently forced to rely on the scheduled task's own firing frequency as a proxy for the heartbeat, which is much coarser and loses the adaptive backoff behavior.

Suggested fix

Either:

• Raise the sleep threshold (e.g. allow up to 300s), or
• Allow sleep when the agent explicitly states intent (opt-in via a comment or flag), or
• Treat sleep inside a pipeline (sleep 30 && poll_command) differently from a bare sleep call

The current hard 2-second cap is too aggressive — it blocks legitimate use cases while the error message itself admits deliberate pacing is valid.