Bash tool: the sandbox stays on after a failed start, and shell parsing is tightened

What

The Bash tool runs shell commands for Claude. A sandbox is a walled-off space that limits what those commands can touch.

• When the sandbox fails to start and a new keepsSandboxOn setting is true, Claude Code refuses the command and keeps sandboxing on. It says "This command of Claude Code's own was not run; the sandbox stays on, and the next command tries to start it again." Before, a failed start turned sandboxing off for the rest of the session. The Bash tool passes keepsSandboxOn to the sandbox setup, the command wrapping and the command runner.
• When Claude Code recovers from exit code 126 (a "cannot run" error), it now records how the command text was delivered, as no_sha256sum or text_unconfirmed. Extra arguments can be added after getSpawnArgs when the shell is started.
• The shell reader now recognises $'...' strings as an ansi_c_string token and skips $$. The permission and safety checks can then read these forms correctly instead of misreading them.
• The parser's feature table gains closingBraceHeld, and keepsTheFiles flags appear alongside it. A new step when permission rules are added to the state was not traced.
• A new scanner reports reasons such as control_byte, open_heredoc and comment. It is used with the server-controlled switch tengu_moonlit_crayon, and nothing has been read about that switch.

The description Claude is given for the Bash tool is unchanged in the capture taken under this release.

Why

If the sandbox fails to start, later commands no longer run without its protection for the rest of the session. Better reading of quoting forms can change which Bash commands are allowed automatically and which are flagged.