What happened?
Foreground shell sleep interception blocks every standalone sleep >= 2s. That is useful for preventing agents from idling in the foreground, but it also blocks a legitimate retry/backoff pattern: an agent may need to wait for an MCP or tool rate-limit window before trying again.
Today a command such as sleep 30 is rejected, and an ordinary trailing comment such as sleep 30 # wait for rate limit reset is intentionally still treated as a blocked standalone sleep. There is no small, explicit, auditable escape hatch for the legitimate rate-limit backoff case.
What did you expect to happen?
The shell guard should keep blocking accidental foreground sleeps and chained sleeps, but allow an explicitly intentional standalone delay for rate-limit backoff or deliberate pacing. The escape hatch should be hard to trigger accidentally and should not allow hiding follow-up commands behind comments or newlines.
Client information
Client Information
This is a code-level behavior in the shell tool validator on current main, not a client-specific runtime failure. Platform used for local validation: macOS.
Login information
N/A — this does not depend on an auth provider.
Anything else we need to know?
This is a follow-up to the sleep interception behavior introduced with the Monitor work in #3684 and related to the background task roadmap in #3634.
What happened?
Foreground shell sleep interception blocks every standalone
sleep >= 2s. That is useful for preventing agents from idling in the foreground, but it also blocks a legitimate retry/backoff pattern: an agent may need to wait for an MCP or tool rate-limit window before trying again.Today a command such as
sleep 30is rejected, and an ordinary trailing comment such assleep 30 # wait for rate limit resetis intentionally still treated as a blocked standalone sleep. There is no small, explicit, auditable escape hatch for the legitimate rate-limit backoff case.What did you expect to happen?
The shell guard should keep blocking accidental foreground sleeps and chained sleeps, but allow an explicitly intentional standalone delay for rate-limit backoff or deliberate pacing. The escape hatch should be hard to trigger accidentally and should not allow hiding follow-up commands behind comments or newlines.
Client information
Client Information
This is a code-level behavior in the shell tool validator on current
main, not a client-specific runtime failure. Platform used for local validation: macOS.Login information
N/A — this does not depend on an auth provider.
Anything else we need to know?
This is a follow-up to the sleep interception behavior introduced with the Monitor work in #3684 and related to the background task roadmap in #3634.