Claude Code 2.1.268: leaked secrets, patched permissions, fixed third-party endpoints

Claude Code 2.1.268 shipped on September 10, 2026, one day after 2.1.267 covered in the previous digest. Security is still the thread running through this one, but on a different front: two ways to get around a permission check, two places where secrets leaked into error messages, and a permission hook that simply didn't fire in automated mode. Alongside that, a regression that broke Claude Code outright for anyone on a third-party endpoint, and a silent file-loss bug in long cloud sessions.

Two ways around a denial, and two leaked secrets

On macOS, /etc, /tmp and /var are themselves symlinks to their real location, and the same goes for /bin on some Linux distributions. A deny or ask rule written against those paths didn't apply when the path given pointed straight at the real location instead of the symlink. That's the opposite of what the permissions documentation describes: a deny rule is supposed to apply as soon as either the symlink path or its target matches, unlike an allow rule, which needs both. The bug let through exactly the case that rule exists to cover.

A second bypass, this time on Read and Edit: a deny rule didn't apply when the command contained env -C, eval, or a similar construct the permission checker can't parse, on the same line as the actual file access. Wrapping a denied access inside a command Claude Code couldn't decompose was enough to slip past it.

Two more fixes, this time about secrets: plugin and marketplace errors could display a token or password embedded in a git source URL, and MCP server details (/mcp, /plugin, claude mcp list/get, sign-in errors) could show a secret resolved from a ${VAR} placeholder in an MCP config. Either way, a secret that should never have left its environment ended up printed on screen, potentially into a log file or a screen share.

The safety net that was missing in automated mode

A PermissionRequest hook fires, per the hooks documentation, when a tool call needs a permission decision: it's the integration point with the permission system itself, whereas a PreToolUse hook runs before every tool call, whether or not that call needs permission. 2.1.268 fixes a case where this hook simply didn't fire at all in --print mode. In practice, an automated pipeline driving Claude Code with -p and relying on this hook to approve or deny actions was running without that gate, with no warning. Same kind of signal lost to automation: policy-helper warnings weren't printing on headless (-p) runs either. If you have that kind of script in production, make sure you're on 2.1.268.

Three tweaks at the edge of trust

A teammate respawned in the same process could inherit tools or a system prompt from a same-named agent file found in a folder you hadn't explicitly trusted, sidestepping the trust confirmation that folder should have required. Fixed.

Next, a rule change rather than a bug: deny and ask rules written against bare WebFetch, with no domain specifier, no longer apply to Artifact tool reads and updates. Artifact isn't listed in the rule format table, so it only takes its bare tool name. If you had a bare WebFetch rule and were counting on it to also cover Artifact, it no longer does: you need a dedicated Artifact rule now, or a WebFetch(domain:claude.ai) one.

Finally, in local Cowork sessions configured to skip every approval, the Artifact tool now refuses a local file outside the session's folders, or hidden behind a symlink, instead of quietly reading it.

The regression that broke third-party endpoints outright

Since 2.1.265, every turn failed with an HTTP 400 error on third-party Anthropic-compatible endpoints, the ones set up through ANTHROPIC_BASE_URL. The cause: a regex in the Artifact tool's input schema that those endpoints rejected. If you run Claude Code against a compatible proxy or gateway rather than directly against the Anthropic API, you were blocked for two full versions, with nothing you could do on your end except wait for this fix. It's resolved in 2.1.268.

Silent file loss in long cloud sessions

On Claude Code on the web, a cloud session running longer than about six hours silently lost files saved to the session's persisted folders, with no error or warning. Saves now persist for up to a day. If you run routines or long-lived cloud sessions that write files as they go, the six-hour limit is the one that just went away.

TaskCreate and TodoWrite are no longer on by default everywhere

The task-tracking tools, TaskCreate, TaskGet, TaskUpdate, TaskList and TodoWrite, are now offered by default only on Claude 3.x, Opus 4.0 through 4.7, Sonnet 4.0 through 4.6, and Haiku 4.5. On newer models, including Opus 4.8, Opus 5, Sonnet 5 and the Fable models, they disappear by default: you need to set CLAUDE_CODE_ENABLE_TODO_TOOLS=1 to get them back. If you were relying on automatic task tracking with a recent model, this is exactly the kind of default-behavior change that breaks a habit without warning.

Everything else, briefly

• claude plugin install, uninstall, update, enable, disable now accept --json, and claude plugin list --json gains errorDetails and noteDetails on every row.
• /plugin now applies an install, enable or disable as soon as you close the menu, no more need to run /reload-plugins afterward.
• Sustained high CPU usage in long-running idle sessions, caused by a busy loop that pinned a CPU core, is fixed, along with the CPU staying high after rapid terminal focus reports during a session recap.
• WebFetch no longer hangs indefinitely on a server that keeps the response open without finishing: a fetch now fails after 300 seconds, and CLAUDE_CODE_WEBFETCH_DEADLINE_MS overrides that deadline (0 turns it off).
• Bash sandbox guidance no longer claims a confinement it doesn't enforce when filesystem isolation is turned off.
• Claude in Slack no longer loses its Slack tools when an organization's managed settings set an MCP allowlist.
• New gatewayInternalNetworks setting to allow /login to a Claude apps gateway from an organization's own public IPv4 block, plus a startup warning when access_control.allow_cidrs is empty.

What to take away

If you're a solo user on a regular claude.ai account, the line in this digest that touches you most directly is the one about TaskCreate and TodoWrite: on Opus 5, Sonnet 5 or a Fable model, automatic task tracking no longer switches itself on. Everything else targets specific audiences: automation scripts running -p that lean on a PermissionRequest hook, setups routed through ANTHROPIC_BASE_URL that were flatly broken for two versions, and long cloud sessions whose files no longer vanish after six hours. A lot of small locks closed this time, spread across different surfaces rather than one recurring mechanism.