Claude Code 2.1.292: six security gaps closed in one release

2.1.292 of Claude Code, released October 6, 2026, has 92 entries, many of them targeted fixes for plugin and mod authors, or fixes specific to Slack, cloud sessions, and Code Review. In the middle of that pile, six distinct fixes, one of them explicitly labeled "Security" in the changelog itself, all touch the same thing: a control that was already in place, on the sandbox, on a managed setting, or on a file path, that didn't hold in one specific case. Three touch the sandbox and managed settings, two concern reads of files that were already approved, and the last one closes a classic Windows disguise for rm -rf. Taken together, this is a notable concentration of security fixes for a single release.

The sandbox and managed settings: when the control itself can be tampered with

The Bash sandbox mostly restricts writes and network access for shell commands. Reads stay broad by default, the doc says so directly: they cover "most of the machine, including credential files such as ~/.ssh and ~/.aws/credentials," unless you explicitly list a path to deny. The first fix closes an access path that default doesn't explain: a sandboxed command could read the staged copies of files uploaded through /ultrareview, stored under ~/.claude/seed-admin. Those copies hold the content you upload for a review, not ordinary project files, and nothing justified a sandboxed shell command reaching them.

The second touches a subtler case, on the read-deny rules themselves. The same doc states that Claude Code "merges the deny entries from every settings scope the session loads [...] any scope can add one, but no scope can remove one that another scope added": a deny rule only ever narrows access, and no settings scope can weaken it. The changelog fixes a case where a read-deny path, managed by your organization or by yourself, that appeared or got re-pointed after the session had already started, didn't drop project grants inside that path, and didn't stop credential injection from the files it covers either. A rule meant to only tighten that, in this one case, stayed open.

The third protects the guard itself. On a managed machine, Claude Code loads a built-in policy plugin, cc-plugin-sec-default, ahead of any mod a user installs. The mods admin doc describes it as a guard that "fails closed: if the guard can't read managed settings, it refuses every user's mod at load." That's the intended behavior when the live fetch of managed settings fails. 2.1.292 closes a different route to the same failure: a local cache of those settings, tampered with on disk, could disable or unseat that guard during exactly that kind of live-fetch failure. A cache you can edit on disk shouldn't be able to switch off the guard that's supposed to hold when everything else has already failed.

A link that changes under the control's nose, and an rm -rf that doesn't recognize its target

The next two fixes share the same principle the permissions doc states for symlinks: once a path is approved, Claude Code checks it still leads to the same place before opening it, and "when a tool then opens the approved file, it confirms that the path still resolves to the location the permission check approved." The first fixes a case where that second check wasn't enough: on macOS and Windows, reading a notebook or a PDF could return a file outside what had been approved, through a link swapped in mid-read. The second touches a different path to the same kind of problem, this time on Windows: the doc explains why a network (UNC) path normally triggers a prompt, even for a read-only command, "because accessing a network path can send your Windows credentials to the host it names." 2.1.292 closes a case where that prompt didn't trigger for a file read approved through a PreToolUse hook or auto mode, exactly the kind of path the rule was meant to cover.

The last fix in this batch touches a command, not a file path. On Windows, a folder often has two names: the usual long name, and a short 8.3-format name (PROGRA~1 for Program Files, for instance), kept around for compatibility with older filesystems. An rm -rf run against that short name, or against another alternate spelling of the home folder or a drive, wasn't recognized by the protection meant to stop Claude from deleting those directories. The command targeted the same place under a different name, and the protection didn't see through the disguise.

Everything else, briefly

• claude plugin install --marketplace <source>: adds the marketplace if needed, under the same policy checks as a manual add, then installs the plugin from it.
• Sub-agent effort: the Agent tool now takes an effort parameter, so a sub-agent runs at the reasoning level you ask for instead of the default one.
• Local MCP: connections to local (stdio) MCP servers now negotiate a newer protocol version by default, including on Bedrock, Vertex, and Foundry; MCP_PROTOCOL_NEGOTIATION=legacy opts back out.
• Sub-agents and auto mode: a sub-agent defined with permissionMode: auto entered auto mode even when auto mode was unavailable (disabled by settings, tripped circuit breaker, or an unsupported model). Another permissions fix: a skill's or slash command's allowed-tools rule came back in a later turn when you left auto mode or plan mode partway through a turn.
• Hooks and <system-reminder>: <system-reminder> tags written in a hook's output are now escaped before they reach Claude, so they can no longer pass themselves off as a system tag.
• Unreadable files: Grep and Glob used to report "no matches" with no error when the given path couldn't be read; Claude now retries once or tells you.
• @-mentioned files over 256KB: used to be dropped silently; Claude is now told the file's size and asked to read it in portions.
• Plan mode: didn't always restore when resuming a session with claude --resume or /resume.
• Scheduled tasks: ones created after /resume, /branch, or /clear never fired; after two writes to the tasks file milliseconds apart, saved tasks also ignored later creates and deletes.
• Cloud sessions, Claude Tag in Slack, Code Review, and VS Code also got their share of fixes, mostly display and reliability issues specific to those surfaces, and about twenty entries are about plugin and mod development, with no effect if you don't write either.

What to take away

None of these six fixes announces a gaping hole on its own: each closes one specific case, a disguised command, a link that changes at the wrong moment, a cache you can tamper with on disk. But their number and variety in a single release matter more than any one of them alone. If you manage mods or managed settings for a team, the third fix, on the built-in guard, is the one to remember: even a tampered local cache shouldn't be able to switch it off anymore. If you read PDFs and notebooks on macOS or Windows, or run Claude Code on a Windows machine where 8.3 short names still exist, those two fixes apply to you directly. For everything else, this release confirms what this digest has been saying for weeks: the permission guardrails mostly hold, and that's exactly why every gap that still slips through is worth tracking down, one at a time.