What
Some commands, such as dangerous removals with rm, trigger a safety check that asks you before running. This release adds a timer to those prompts and new handling in the auto and bypass permission modes.
- The safety check behind dangerous removals,
dangerousRemoval, is now markedautoModeDeny. In auto mode, or plan mode with auto active, such a check is treated as needing a person rather than something auto mode can approve. - Instead of falling back to a plain question, Claude Code either denies the command outright or shows a permission dialog with an auto-deny window (
autoDenyWindow). If you do not answer before the window ends, the command is denied. - In
bypassPermissionsmode, the same checks can now show this timed dialog when an interactive dialog is available. Before, there was no dialog path. IfshowDialogis off or no dialog can be shown, the command is denied immediately. - After a set number of unanswered prompts in one session, Claude Code stops showing the dialog and denies straight away. The count resets when you allow or deny a prompt.
- These prompts no longer offer an "always allow" rule when the reason cannot be approved automatically (
suppressAlwaysAllowRule). - The behaviour is controlled by the server config
tengu_splendid_horizon. Nothing has been read about that config for this release. Its built-in fallbacks areenabled: true,showDialog: true,timeoutMs: 120000(2 minutes) andmaxDialogTimeouts: 3. - The server can set the timeout between 5,000 and 3,600,000 milliseconds, and a value outside that range is not used as given. A server
enabledvalue counts only when it arrives in the config payload. - Setting the environment variable
CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUTturns the feature off.
Why
A dangerous-command prompt in an unattended session no longer waits forever. It resolves to a deny, which is the safe outcome, and after three unanswered prompts the session stops asking. If you would rather such prompts wait for you indefinitely, set CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT.
Names in the bundlebypassPermissions
The entry above is what we published on the day. These lines were added later, as Anthropic's own pages caught up, and they sit beside the original rather than replacing it.
Added since
A small documentation edit on Continue local sessions from any device with Remote Control touched a line naming bypassPermissions after this was published.
| `--chrome` / `--no-chrome` | Turn [Chrome integration](/docs/en/chrome) on or off in the sessions the server creates, so Claude can use Chrome on your machine while you work from another device. Without either flag, the session the serve…remote-control see the edit
Confirmed since
Anthropic's documentation has since written up bypassPermissions, on Choose a permission mode.
* **A glob or trailing slash under a variable such as `$DIR`**: guard each expansion so the shell stops with an error when the variable is unset or empty, as in `rm -rf "${DIR:?}"/*`, or use a literal path. A removal whose expansions are a…permission-modes see the edit
Two sources agreeTwo things we can check say the same as this entry.
Anthropic's documentation agrees
Anthropic's documentation has since written up bypassPermissions, on Choose a permission mode.
Anthropic's release notes agree
Improved screen-reader output in /mcp: a disabled server is read as "off" instead of "pending"