Claude Code 2.1.265-266: a plugin security bypass closed, Windows sandbox fixed

A disguised symlink path was slipping past the plugin security check, the Windows sandbox rejected every file, and an LLM gateway broke authentication for a day.

claude-code changelog securite digest-dossier

Two releases back to back on September 8, 2026: 2.1.265 first, then 2.1.266 the same day to fix a regression the first one had just introduced. The thread running through this double release isn't a new feature, it's hardening: a plugin-loading security bypass closed, a Windows sandbox that blocked Claude Code entirely, and a same-day fix for LLM gateway authentication.

A backslash in a plugin path was bypassing the security check

When Claude Code loads a plugin, it checks that the plugin's symlinks stay contained inside the plugin's own directory: a plugin shouldn't be able to point, through a symlink, at a file living elsewhere on your machine. 2.1.265 closes a way around that check on macOS and Linux, when the plugin's path contained a backslash. Backslash isn't a path separator on those systems, but the check apparently treated it as one, letting through a path that the filesystem's actual resolution interpreted differently.

The docs on installing plugins are blunt about what a plugin represents: "plugins and marketplaces are highly trusted components that can execute arbitrary code on your machine with your user privileges." The symlink containment check is exactly what's supposed to put a limit on that trust once a plugin is loaded. Bypassing it didn't hand a malicious plugin access it couldn't theoretically already reach, but it removed one of the guardrails meant to limit the damage from a plugin that turns out to be malicious or compromised. If you build or distribute plugins, there's nothing to do: the fix is transparent, but it's worth knowing it existed.

Windows: the sandbox stopped blocking one file and started blocking all of them

On Windows, when Claude Code ran inside an AppContainer or a restricted token (the mechanisms an enterprise policy or a third-party sandboxing tool impose on the process), Read, Write and Edit flatly refused every single file, with the error "symlink resolution changed after permission was checked." In practice, the tools could no longer read or write anything in that context, making Claude Code unusable for anyone working inside a locked-down Windows environment set up that way. 2.1.265 fixes the bug.

This isn't Claude Code's own built-in sandbox, the one you turn on with /sandbox: that feature still isn't supported on native Windows, where the recommendation remains to run inside WSL2. This bug hit sandboxes imposed from outside Claude Code, by the operating system or by a workstation policy. If you deploy Claude Code to managed Windows machines with that kind of restriction, this update is worth pushing out first.

A same-day fix for LLM gateways

2.1.265 also unintentionally introduced a regression for setups routed through an LLM gateway (an enterprise proxy sitting in front of Anthropic or another provider). The undocumented CLAUDE_CODE_USE_GATEWAY environment variable, previously ignored unless both ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN were set, started forcing a Cloud-gateway sign-in on its own. Any configuration that set it alongside an API key, an apiKeyHelper, or custom auth headers had every request fail with "Not signed in to the Cloud gateway."

The docs on connecting to an LLM gateway describe how an organization distributes a gateway URL and credential, through managed settings, device management or an apiKeyHelper, and state that this credential takes precedence over a saved claude.ai login, which stays in place but unused. That is the mechanism the regression short-circuited: the variable forced a Cloud-gateway sign-in before the configured credential ever got its turn, instead of staying inert by default. 2.1.266, shipped the same day, restores the original behavior with nothing to reconfigure on your end. If you manage a fleet with that variable set in the environment, just confirm you're running 2.1.266 or later.

Everything else, briefly

  • --plugin-dir now accepts a folder holding several plugins: each subfolder with a manifest loads, and one added or removed while Claude Code is running gets picked up.
  • Tool results saved to disk are now capped at 1 GB, with the in-conversation preview flagging when a file was truncated for that reason.
  • Prompt-cache reuse was being lost in two cases: resuming a foreground-spawned subagent, which changed its tool list and system prompt prefix, and agent teammates and resumed subagents, which moved SubagentStart hook context and preloaded skills out of the prompt prefix on later turns. Both are fixed.
  • MCP servers configured as http transport that actually only speak the legacy SSE transport never connected at all: Claude Code now falls back to SSE, as the MCP spec describes, with nothing to reconfigure on your side.
  • A cd inside a non-interactive session (-p with stream-json input, Agent SDK, cloud sessions) now persists from one turn to the next, instead of resetting on every new message.
  • VS Code now automatically archives sessions that have been inactive for a while, defaulting to fourteen days, with a new setting to change that window.
  • Resuming a session interrupted while a tool was running no longer rewrites the last prompt: the interrupted tool call is kept and marked as such, instead of being lost.
  • Reading an artifact someone else published now treats its content as untrusted and flags instructions hidden inside it, instead of relaying them as if they were legitimate.
  • A remote MCP server that requires sign-in no longer gets an OAuth client registered until you actually authenticate with it.
  • Machines with forceLoginGatewayUrl in managed settings now run as Claude apps gateway sessions from startup, like forceLoginMethod: "gateway": a leftover claude.ai login or API key is no longer used.
  • The telemetry Claude Desktop and Cowork send through a Claude apps gateway now includes user.email and user.groups, matching what terminal sessions already sent.

The bottom line

None of this changes your daily habits if you run Claude Code solo with a regular claude.ai account. These two releases target specific audiences: plugin authors and users for the security bypass, teams deploying Claude Code on locked-down Windows machines for the sandbox fix, and LLM gateway admins for the same-day patch. In all three cases, the only thing worth doing is confirming you're on 2.1.266, since the regression was introduced and fixed within a single day.

Pierre Rondeau

Pierre Rondeau

Developer and indie builder. I build products and automations with AI. Creator of Claude Hub.

LinkedIn