title: "Claude Code v2.1.282 (Sep 24): Managed-Settings Hardening Closes Three Attack Classes" slug: claude-code-2-1-282-managed-settings-hardening-macos-symlink-plugin-self-approval-sep-2026 date: 2026-09-24 author: Mr. Technology category: AI News type: news source: Original priority: high pillar: false published: true status: published publishedAt: 2026-09-25T14:09:00Z cover_image: '' primary_sources:
excerpt: "v2.1.282 ships three security fixes that change the threat model for managed Claude Code deployments."
On 2026-09-24 at 18:37:49 UTC (release page updated 2026-09-24T18:38:05Z), Anthropic published Claude Code v2.1.282. It is the densest security-and-managed-settings-hardening release of the September series by line count, and the first that materially changes the threat model for anyone running Claude Code under a managed configuration.
This is a documentation comparison article. Every claim is sourced verbatim from the GitHub release page for v2.1.282 and the anthropics/claude-code atom feed. No firsthand test was run.
v2.1.282 is distinct from v2.1.281 (Sep 22-23, covered on this site at /payloads/claude-code-2-1-281-bedrock-guardrail-rm-substitution-mcp-validate-sep-2026). v2.1.281 made Bedrock assume_role + guardrail available on the Claude apps gateway, added claude plugin validate MCP checks, and closed the rm -rf "$(pwd)" / macOS /.vol / NUL-byte permission-rule class. v2.1.282 does not share a change set with v2.1.281; it is a different cluster (managed-settings hardening + a different macOS path fix + an operational gateway addition).
1. macOS CLAUDE.md and rules path traversal via repository symlinks (release page verbatim): "Fixed CLAUDE.md and rules being read at startup through a repository symlink reaching macOS's /Network via .. or a /.vol-style kernel path, or a rules link to macOS's /home being listed." Before this fix, a repository symlink (for example a CLAUDE.md path that resolves through .. to /Network) could cause startup-time reads of CLAUDE.md to traverse macOS synthetic filesystem paths that ultimately resolve to a network mount, with the read happening before user approval. After the fix, those paths are not followed at startup. This is the pre-startup data-leak class that v2.1.281's /.vol permission-dialog fix covered for the post-approval phase; v2.1.282 closes the same class at the pre-startup phase for symlinked CLAUDE.md / rules files.
2. Managed boolean lock-key typo bypass (release page verbatim): "Fixed managed settings ignoring a mistyped value for boolean lock keys such as disableClaudeAiConnectors or allowManagedPermissionRulesOnly; the lock now applies and startup names the key." Before this fix, a managed admin who set disableClaudeAiConnectors: ture (typo) or allowManagedPermissionRulesOnly: 1 (numeric instead of boolean) would have had the lock silently dropped — the key was treated as missing rather than as an error, and the corresponding connector or rule bypass was active. After the fix, the lock is enforced regardless of typo, and startup prints the offending key so the admin knows it was applied. This is a defense-in-depth item for every managed Claude Code fleet.
3. Plugin-manifest self-approval bypass under allowManagedPermissionRulesOnly (release page verbatim): "Fixed repository, user and --add-dir skills, commands and skills-directory plugin manifests pre-approving their own tools via allowed-tools under managed allowManagedPermissionRulesOnly." The allowManagedPermissionRulesOnly lock is the managed-settings knob that prevents user/repo/plugin rule files from granting their own tool permissions. Before this fix, a plugin manifest could ship an allowed-tools: [...] block that effectively pre-approved the plugin's own tools, bypassing the very purpose of the lock. After the fix, plugin-manifest self-approvals are no longer honored under allowManagedPermissionRulesOnly.
Three additional managed-settings fixes improve posture without being individually headline items:
permissions, autoMode, worktree and attribution settings being ignored entirely when one nested value was invalid; the rest of the block now still applies." Before this fix, a managed admin who wrote one bad nested value (for example autoMode.someArray: null or attribution.shape: undefined) would have had the entire managed block silently dropped, with no log line. After the fix, the rest of the block still applies — only the offending nested value is skipped.Skill(anthropic-skills:</em>) and Skill(claude-ai:<em>) allow rules to cover only skills synced from claude.ai, not plugins or other skills that merely use such a name. Changed skill folders, command files and workflow commands in the anthropic-skills or claude-ai namespace to no longer load; a plugin so named still loads but yields name ties to synced skills." The anthropic-skills and claude-ai namespaces are reserved for skills synced from claude.ai. Before this fix, a plugin whose name collided with that namespace would either load as a namespace override or fail to load. After the fix, only synced claude.ai skills land in those namespaces, plugins with the same name load normally but yield name ties to synced skills, and skill folders / commands / workflows in those namespaces no longer load at all. The corresponding MCP fix: "Changed MCP servers configured under the name anthropic-skills or claude-ai to list no skills or prompts (their tools still work); rename the server in your MCP configuration to list them again."/etc/claude-code from applying." Before this fix, an invalid or unreadable admin policy would prevent the user-writable settings from applying (a fail-closed default for managed fleets). After the fix, user-writable settings still apply when admin policy is unreadable — a fail-open default that gives the user their usual configuration in the (presumably rare) case of an unreadable admin policy.Three items change the operational behavior of a Claude Code deployment without being security-relevant:
store.readiness_grace_seconds on the Claude apps gateway. (Release page verbatim): "Added store.readiness_grace_seconds to the Claude apps gateway so /readyz can stay ready through a short Postgres outage such as a database failover." This is the operational unlock for anyone running Claude Code behind a gateway with Postgres-backed state. Before this setting, /readyz would flip to not-ready on any Postgres read failure, taking the gateway out of rotation during failovers. After this setting, a configurable grace window keeps /readyz returning ready through short outages. The release page does not specify the default; the typical default is 0 / disabled for backward compatibility, requiring the operator to opt in.:* now work in settings files** (release page verbatim): "Fixed Bash permission rules with a mid-pattern :</em> being skipped in settings files while --allowedTools honored them; they now work from every source, with a startup warning on how they match." Before this fix, a Bash allow rule like Bash(git </em>:<em>) (literal :</em> mid-pattern) was honored only when passed via --allowedTools, not when in settings.json or settings.local.json. After the fix, the rule matches from every source, and a startup warning prints to make the match behaviour visible.CLAUDE_CODE_AUTO_MODE_SERVER=0 opts out)." This is a behavior change: when telemetry is off and Claude Code is connected directly to the Anthropic API (not via Bedrock, Vertex, or Foundry), auto mode now uses the server-side classifier by default. The opt-out is the new CLAUDE_CODE_AUTO_MODE_SERVER=0 env var.Two additional items close telemetry export control paths that v2.1.281's Bedrock-side hardening did not cover:
CLAUDE_CODE_ENABLE_TELEMETRY and OTEL_LOG_</em>."* Before this fix, a non-managed project or local settings file could turn on OpenTelemetry export to a third-party endpoint via env-var style keys. After the fix, only managed settings can do that./status + claude doctor list ignored telemetry variables (release page verbatim): "Added a startup notice, and /status and claude doctor entries, listing telemetry variables in a project's settings files that were ignored or that turned telemetry off." This is the observability surface for the previous item — operators can now see which telemetry variables in their project settings were silently ignored.Several other items in v2.1.282 are operationally relevant but do not rise to the level of individual coverage:
--continue, --resume) re-sending earlier messages in a changed form, which could make the API drop Claude's earlier reasoning. This is the same class as the v2.1.281 session-resume fidelity fix, applied more broadly./model, /rename, /artifacts or another immediate slash command was used while Claude was working — a long-standing UX bug.compact-2026-09-04 beta.claude remote-control --debug failing with "Unknown argument: --debug", although Remote Control's own eligibility error says to run with --debug — small but worth flagging for anyone running Remote Control sessions.claude-api skill: pre-output refusal billing now links to the How-refusals-are-billed docs, mid-stream refusals bill at normal rates, and pre-output refusals count against rate limits. (This is a documentation update to the bundled skill, not a platform change — the platform change was Sept 24, covered at /payloads/anthropic-refusal-billing-expansion-bio-frontier-llm-reasoning-extraction-sep-2026.)sandbox.excludedCommands now ignores project and local settings entries when managed settings or --settings set allowUnsandboxedCommands: false, or managed allowManagedDomainsOnly: true. Defense in depth.The v2.1.282 release page also contains ~25 additional UI/UX and bug-fix items (vim mode correctness, scrollbars in /feedback and /skills, PDF page-read error message fixes for paths with accented characters, etc.). These are individually narrow and below the materiality bar for this article; the release page is the canonical reference.
If you run managed Claude Code fleets: the three security fixes change your threat model. The lock-key typo bypass meant your managed config could be silently disabled by a single character mistake in your disableClaudeAiConnectors or allowManagedPermissionRulesOnly line. The plugin-manifest self-approval bypass meant a plugin could grant itself the tools it needed regardless of the lock. The macOS CLAUDE.md path-traversal fix means a malicious repository can no longer use a symlink in its CLAUDE.md to read macOS synthetic paths at startup time. These are not marketing items; they are exactly the items an enterprise security review should see before approving a v2.1.282 upgrade.
If you operate a Claude apps gateway with Postgres-backed state: store.readiness_grace_seconds is a one-line operational unlock. A 30-second Postgres failover used to take the gateway out of rotation; with this setting configured, you can ride through it. The setting is opt-in (the release notes do not state a default; treat the default as 0 / disabled for backward compatibility) so you have to flip it.
If you have ever mixed Claude Code sessions with a third-party Anthropic-API-compatible gateway (LiteLLM, OpenRouter-with-Claude, custom proxies): the web-search decryption 400 fix removes a recurring source of session-failures. Worth flagging on the upgrade checklist.
**If you ship Bash permission rules with mid-pattern :*:** the rule-match consistency across --allowedTools and settings files removes a long-standing footgun where a rule worked on one surface but not another.
If you operate Claude Code with telemetry off and a direct Anthropic API connection: auto mode now uses the server-side classifier by default. The opt-out CLAUDE_CODE_AUTO_MODE_SERVER=0 is documented in the release notes; the behavior change is meaningful for any team whose auto-mode observability was previously local-only.
Verification level: documentation comparison. Primary sources verified verbatim at fetch 2026-09-25T14:09–14:10 UTC:
github.com/anthropics/claude-code/releases/tag/v2.1.282. Release-page body contains 5 Added entries and ~50 Fixed entries; the relevant ones are captured verbatim in the What Actually Changed sections above.github.com/anthropics/claude-code/releases.atom. Feed <updated>2026-09-24T18:37:49Z</updated>; v2.1.282 entry id tag:github.com,2008:Repository/937253475/v2.1.282, updated 2026-09-24T18:38:05Z./payloads/claude-code-2-1-281-bedrock-guardrail-rm-substitution-mcp-validate-sep-2026 confirming v2.1.282 is a distinct release (no shared change set).What this article did not independently verify:
allowed-tools block under allowManagedPermissionRulesOnly: true.store.readiness_grace_seconds during an actual Postgres failover — the release-page wording is the primary documentation.CLAUDE_CODE_AUTO_MODE_SERVER=0 opt-out behavior.Cost. None directly. None of the v2.1.282 additions or fixes carry a per-request token cost beyond what Claude Code already bills. store.readiness_grace_seconds is a gateway configuration knob with no API cost.
Risk.
disableClaudeAiConnectors: ture (typo) and relied on the bypass being active will, after upgrading to v2.1.282, have the lock applied — meaning the connectors will now be disabled as the admin originally intended. This is the correct behavior, but it is a behavior change, and any managed admin should audit their settings for typos before rolling out v2.1.282 fleet-wide.allowed-tools block self-approves their tools will, after this release, lose that self-approval under managed allowManagedPermissionRulesOnly. If you ship plugins for Claude Code and you have an allowed-tools block that grants your plugin's own tools, you should be aware that your plugin's permissions in managed environments now require explicit per-tool grants in the lock file rather than relying on the manifest's allowed-tools... to /Network will find those paths no longer resolve at startup. This is the correct behavior for security, but any operator who was unintentionally relying on a symlink to load a network-share CLAUDE.md will see startup reads fail. Audit your symlink layout before the upgrade.CLAUDE_CODE_AUTO_MODE_SERVER=0 to restore the previous behavior, or accept the new server-side-classifier default.Limitations.
store.readiness_grace_seconds default is not documented in the release notes. Treat the default as 0 / disabled for backward compatibility; verify by inspecting the gateway startup logs after upgrade.v2.1.282 is the managed-settings-hardening release of the September series, complementing v2.1.281's enterprise-Bedrock + plugin-validate release. The cluster that matters is three security fixes (macOS CLAUDE.md path traversal, boolean lock-key typo bypass, plugin-manifest self-approval bypass) plus the managed nested-value drop, the skill-namespace hardening, and the Windows/WSL admin-policy preference flip. The operational cluster — store.readiness_grace_seconds, Bash :* consistency, auto-mode server-side classifier default — is the second tier. The reliability sweep (continued-session fidelity, thinking-on-slash-command preservation, compaction-on-refusal fallback, the third-party-gateway decryption 400 fix) is the third tier.
The headline risks are narrow and well-flagged in the release notes. The headline opportunity is that any team running Claude Code under managed settings — particularly on macOS, on Windows/WSL, or with Postgres-backed gateway state — gets a meaningful security-posture and operational-resilience upgrade from this release.
Today 1. Audit your managed settings for typos in lock keys (disableClaudeAiConnectors, allowManagedPermissionRulesOnly, and any other boolean lock key). v2.1.282 will enforce the lock regardless of typo, so any typo'd key that was silently bypassed before will now actually apply. Verify that the resulting behavior is what you intended. 2. Audit your plugin manifests for allowed-tools blocks that self-approve the plugin's own tools. Under allowManagedPermissionRulesOnly, those self-approvals no longer apply. Add explicit per-tool grants in your managed rule file if needed. 3. If you operate a Claude apps gateway with Postgres-backed state, configure store.readiness_grace_seconds to a value larger than your typical Postgres failover window. Verify in a dev environment that /readyz stays ready through a forced failover. 4. If you operate Claude Code on macOS and your repositories use symlinked CLAUDE.md / rules paths, audit the symlink targets. Any path that resolves through .. to /Network or to /.vol-style kernel paths will no longer be followed at startup. If those paths were load-bearing for your workflow, replace them with absolute paths or copy the files.
This week 5. If you run auto mode with telemetry off on a direct Anthropic API connection, decide whether you want the new server-side-classifier default or the previous local-only behavior. If local-only, set CLAUDE_CODE_AUTO_MODE_SERVER=0 before upgrading. 6. **If you ship Bash permission rules with mid-pattern :* in settings files, verify the rules now match. A startup warning will print to confirm; adjust rule placement if the match behavior is unexpected. 7. If you operate Claude Code on Windows/WSL with a managed admin policy that may be invalid or unreadable, verify that your user-writable HKCU settings still apply post-upgrade. The fail-open behavior is the new default. 8. If you operate on a third-party Anthropic-API-compatible gateway** (LiteLLM, OpenRouter-with-Claude, custom proxy) and have web-search results in your session history, run the upgrade and verify the prior decryption-400 class no longer fires.
Skip if not in scope. If you do not operate managed Claude Code, do not run a Claude apps gateway, do not ship plugins, and do not use macOS symlinks for CLAUDE.md, the v2.1.282 release is a security-update + reliability-sweep roll-forward. Pick it up on your normal upgrade cadence.
tag:github.com,2008:Repository/937253475/v2.1.282, updated 2026-09-24T18:38:05Z)Verification level: documentation comparison. Every claim above is verifiable verbatim in the GitHub release page body for v2.1.282 and the atom feed entry timestamp. No firsthand test was run against this release.