claude-code - 💡(How to fix) Fix Bash tool blocks `sleep` as first command — needs opt-out or configurable threshold [2 comments, 3 participants]

Problem

The Bash tool currently blocks any sleep N command (where N ≥ 2) when it appears as the first command in a shell invocation. This forces users and Claude to use workarounds like run_in_background: true or remote-side sleep (ssh server 'sleep 300 && ...').

Why This Matters

In automated workflows (e.g., long-running ML training loops), Claude needs to periodically check on remote processes by waiting a fixed interval and then querying status:

sleep 300 && ssh gpu-server 'tail -50 ~/training.log'

Because sleep is blocked as the first command, you must either:

1. Use run_in_background: true — but this returns immediately, and if the conversation has a stop hook that fires on each response, it creates a cascading problem: each hook trigger spawns another background task, resulting in dozens of orphaned background sleep processes.
2. Prepend a dummy command like echo "wait" && sleep 300 && ... — this works but is fragile and unintuitive.
3. Move sleep to the remote side (ssh server 'sleep 300 && ...') — this works but isn't always applicable (e.g., local file watching, waiting for a local build).

The Stop Hook Cascade Problem

When using automated loops with stop hooks:

1. Claude runs sleep 300 → blocked, must use run_in_background
2. Background task starts, Claude responds immediately
3. Stop hook fires on response → triggers another iteration
4. New iteration starts another sleep 300 background task
5. Repeat → dozens of background sleep processes accumulate

This makes long-running monitoring workflows (ML training, CI/CD pipelines, deployment monitoring) extremely difficult to manage.

Proposed Solution

Add a configurable option to allow sleep as a first command in the Bash tool:

Option A: Setting in settings.json

{
  "bash": {
    "allowSleepAsFirstCommand": true,
    "maxSleepSeconds": 600
  }
}

Option B: Per-invocation flag

Similar to dangerouslyDisableSandbox, add a parameter like:

{
  "command": "sleep 300 && ssh server 'tail training.log'",
  "allowSleep": true
}

Option C: Increase the threshold

The current threshold of 2 seconds is very conservative. Raising it to 30-60 seconds would cover most polling use cases without significant risk.

Environment

• Claude Code CLI (macOS)
• Workflow: Automated ML training loop with stop hooks for continuous iteration
• The workaround of remote-side sleep (ssh server 'sleep N && ...') works but isn't a general solution

Workaround

For SSH-based monitoring, move the sleep to the remote server:

ssh server 'sleep 300 && grep "^ep=" ~/training.log | tail -15'

This avoids the local sleep restriction but doesn't help for purely local waiting scenarios.