Claude Code 2.1.260: Permission Rules Get Stricter, /diff Shows Up

Just one version since the last digest, 2.1.260 from September 3rd. The official changelog lists more than sixty entries, but the throughline is clear: this release revisits what a permission rule, strict sandbox mode, and a managed CLAUDE.md file are supposed to block. It tightens in one place and loosens in another. Alongside that, a new /diff panel lands in fullscreen mode.

Closing the permission gaps

Three fixes patch holes in the permission checks. The widest one first: a rule whose path contains parentheses, say to protect a folder named (archive), was silently dropped by the Bash sandbox instead of being enforced. A folder you thought was protected by a deny rule stayed writable, with no error and no warning. Read and Edit rules follow .gitignore pattern syntax: a malformed rule should block access, not fail quietly.

The second fix covers a related case: a deny rule with an uncompilable pattern, an unclosed [ for instance, made every file edit fail with an Invalid regular expression error, even on paths the rule never targeted. Such a deny rule now guards only the literal path it spells out, instead of breaking every edit tool.

The third is zsh-specific, and it's the kind of trick only someone who knows the shell would exploit: assigning a value to the special parameters REPORTTIME, REPORTMEMORY, or DIRSTACKSIZE can hide a $(...) command substitution that runs right as the assignment happens. The auto mode classifier was approving these as plain variable assignments. They now prompt for approval, in the same family as the [[ ]] conditionals closed in 2.1.257 and already covered in the 2.1.257-258 digest: zsh parses some constructs differently from bash, and auto mode has to keep up.

The sandbox changes behavior, in both directions

Two changes touch the sandbox itself, pulling in opposite directions. On one side, commands typed at the bash-mode prompt, the ! prefix, now run outside the sandbox even when strict sandbox mode is on, the mode the docs describe as ignoring the dangerouslyDisableSandbox escape hatch entirely. The reasoning: typing ! means you're writing directly into your own terminal, not Claude running a generated command. If you manage a fleet and were counting on strict mode to guarantee that no command, generated or typed, ever escapes the sandbox, this is worth checking: bash-mode is now a deliberate exit by design, not a gap someone forgot to close.

On the other side, a 2.1.259 change just got reverted. That same release had widened Read() deny rule coverage to more Bash command forms, a fix the 2.1.259 digest walked through. The unintended side effect: a Read(./**/build/**) rule, written to protect a generated build folder, also blocked npm run build itself, in every permission mode including manual, and made compositions like cd DIR && grep prompt for approval even in auto mode. The fix is pulled until a version ships that doesn't break the most ordinary command in a JavaScript repo.

A managed CLAUDE.md no longer triggers a security dialog

A CLAUDE.md file pushed through managed settings used to trigger the same security approval dialog as a hook or a managed shell command. That's no longer the case: only hooks, shell commands, sandbox settings, and unsafe environment variables still require explicit approval before they apply. The server-managed settings docs list exactly what counts as a setting needing approval, category by category. A plain text instructions file was never able to execute code on its own; dropping it from that list removes a prompt that added no real guarantee, without touching the categories that actually do.

A /diff panel in fullscreen mode

On the feature side, /diff opens a panel beside the conversation in fullscreen mode, showing your uncommitted changes as Claude edits. Until now, checking what had changed meant switching to a git diff in another terminal or waiting for the turn's summary. The same command toggles the panel open and closed.

Three fixes for Fable 5.1

Fable 5.1 picks up three fixes in this release. The /model picker didn't list it for organizations that actually had access to it, only typing the model name directly worked. Prompt caching didn't cover context added after a tool result, so it went back to uncached input on every tool-using turn, inflating the bill for agentic sessions that chain a lot of tool calls. And /effort was invalidating the prompt cache on Fable 5.1: changing effort mid-session no longer does. None of these three change anything about what you need to do: they just deliver what Fable 5.1 already promised at launch, covered in the 2.1.257-258 digest.

Everything else, briefly

• A permission rule with text after the closing parenthesis, like Bash(ls) x, never matched anything and was silently ignored; it is now reported as an invalid setting.
• /cost and the status line's prompt_cache field now name the likely cause of a prompt-cache miss: changed tool definitions, a changed system prompt, or idling past the TTL.
• SDK-provided MCP servers (like Desktop connectors) sometimes went missing on a session's first turn and only showed up on the next one.
• Claude in Chrome failed with "Not connected" mid-task in cloud sessions when a connector was added or removed along the way.
• /rewind reported success even when checkpoint backup files were missing and nothing was actually restored, and left stale file-read tracking behind, causing "File unchanged since last read" stubs after a restore.
• IDE line selections were dropped when running a skill or slash command with lines selected.
• Auto-compact for 1M-context models (Opus, Fable) now kicks in before hitting the limit, and recovery compaction no longer times out at ten minutes on very large contexts.
• GitLab: repository detection now works in nested subgroups, and an owner/repo#123 reference finally links to gitlab.com instead of github.com inside a GitLab repo.
• ctrl+l / cmd+k in fullscreen mode now clears the transcript view like a terminal clear; scroll up to see earlier messages.

The takeaway

If you're an individual user, the one thing worth trying is /diff: reach for it next time you want to check an edit without leaving the terminal for another window. The rest of the permission fixes close gaps you likely never ran into in practice. If you manage a fleet, check two things before trusting strict sandbox mode: that your parenthesized Read and Edit rules actually match what they're supposed to protect, and that your users' bash-mode ! hasn't quietly become the escape hatch out of your isolation boundary.