Dangerous-rm prompt raised by a sub-agent has no auto-deny timeout, stalling unattended bypass-mode runs indefinitely

Status Open
Reported on v2.1.291
Maintainer reply None cached
Activity 2 comments · opened Oct 6, 2026

What's wrong

In bypass permissions mode, the dangerous-removal safety prompt in the main agent shows a countdown ("Claude Code will automatically deny this request in 1:59, to avoid blocking progress on an unattended session") and auto-denies after 120 s, so an unattended run carries on.

When the same prompt is raised by a sub-agent (dialog header "Bash command · from the general-purpose agent"), there is no countdown and no auto-deny. The prompt waits indefinitely and the whole run stalls.

In real use this stalled an overnight run for about 15 hours: a background general-purpose sub-agent raised the prompt at 17:13 and it was still waiting when the user came back at 08:24 the next morning.

Reproduction (2.1.291, Linux / WSL2, also seen on 2.1.289)

  1. Make a test tree: mkdir -p /tmp/t/src/sm/one /tmp/t/src/sm/two && touch /tmp/t/src/sm/one/f /tmp/t/src/sm/two/g && mkdir -p /tmp/t/dst
  2. Start claude --dangerously-skip-permissions --add-dir /tmp/t in any folder.
  3. Main agent: ask it to run exactly cd /tmp/t/src && for d in one two; do mv sm/$d/* /tmp/t/dst/; done && rmdir sm/* sm. The dialog appears with the countdown and auto-denies after 2 minutes.
  4. Recreate the tree. Sub-agent: ask the main agent to launch a general-purpose sub-agent that runs the same command. The dialog appears without the countdown and is still open after 3+ minutes (and indefinitely in the real case).

A command substitution target (rm -rf $(echo /tmp/t/x)) shows the same difference.

Expected

The auto-deny timeout that protects unattended main-agent runs should also apply to prompts raised by sub-agents (foreground and background). Sub-agents are where most unattended work happens, so they are where this matters most.

Notes

  • The dialog's displayed target is also resolved against the shell's previous working directory rather than the cd target (as in #94704), e.g. .../previous-folder/sm/*.
  • Workaround we are using: a PreToolUse hook that returns permissionDecision: "deny" for deletes the checker cannot resolve, with a reason telling the agent to delete by literal absolute paths. The deny pre-empts the dialog and the sub-agent retries successfully. A hook allow does not help, since the check is bypass-immune by design.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗