On September 24, 2026, Anthropic shipped Claude Code v2.1.282. Inside a changelog with more than 80 line items, six of them share a category we’ve covered before: the permission and managed-settings layer — the code that decides what Claude can do without asking, and what an organization’s admin policy is supposed to lock down — failed to enforce what it was supposed to enforce. The official changelog lists each as a single terse bullet with no elaboration, which is normal for Anthropic’s release notes but leaves the practical impact unexplained.
That’s what this post covers. Two of the six are user-facing permission bugs (a CLAUDE.md symlink escape, a skipped Bash rule pattern). The other four are managed-settings bugs specifically — meaning they affect organizations that push policy through managed-settings.json or an MDM profile to lock down what Claude Code can do across every seat, not individual developers configuring their own .claude/settings.json. If you’re on a Team or Enterprise plan with centrally managed policy, four of these six bugs meant that policy wasn’t actually being enforced the way your admin console said it was.
We verified every quote below against the live changelog rather than paraphrasing from memory.
1. CLAUDE.md and Rules Files Readable Through a Symlink Escaping the Repo
The changelog entry: “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.”
What failed: At startup, Claude Code walks the working directory looking for CLAUDE.md and rules files to load as project instructions. The intent is to only read files that are actually part of the repository. This entry describes two related escapes on macOS specifically: a symlink inside the repo that uses .. traversal or one of macOS’s special kernel-mounted paths (/.vol/<device>/<inode>, which resolves to an arbitrary file by raw filesystem identifiers rather than a path) to point outside the repo entirely, reaching macOS’s network-mounts pseudo-directory /Network. A second, narrower case let a rules-directory symlink get listed even when it pointed at a user’s /home directory.
Why it bites you: Project instructions are supposed to be scoped to what’s checked into the repository — that’s the whole trust model behind “clone a repo, run claude, it picks up that repo’s CLAUDE.md.” A symlink that resolves outside the repo (into another mounted volume, another user’s home directory, or a network share) breaks that scoping silently: nothing in the UI distinguishes “this instruction came from a file actually inside the repo” from “this instruction came from wherever this symlink happens to point today.” In a shared or CI environment where repos get cloned from untrusted sources, a symlink checked into the repo is a way to have Claude load and follow instructions from a location the repo author doesn’t control and the person running Claude never reviewed as part of the repo’s own files.
If you clone repositories from outside your organization — open-source dependencies vendored as submodules, contractor handoffs, anything from a public fork — this is worth an explicit audit on macOS: find . -type l in a freshly cloned tree will surface any symlinks, and it’s worth checking what each one actually resolves to before trusting the instructions Claude reports loading.
2. Bash Permission Rules with a Mid-Pattern :* Silently Skipped
The changelog entry: “Fixed Bash permission rules with a mid-pattern :* being skipped in settings files while --allowedTools honored them; they now work from every source, with a startup warning on how they match.”
What failed: Claude Code’s Bash permission rules support a :* wildcard suffix — something like Bash(npm run:*) to allow any npm run subcommand. This bug describes a narrower shape: a :* wildcard placed in the middle of a pattern rather than at the end (for example, something like Bash(git commit:* --amend), a colon-star followed by more pattern after it). When a rule like that was defined in a settings file (.claude/settings.json, user settings, or a managed policy file), it was silently skipped — not applied, not erroring, just absent from the effective rule set. The same pattern passed on the command line via --allowedTools worked correctly; only the settings-file path was affected.
Why it bites you: A silently-skipped allow rule is the safer failure direction — it means Claude prompts for approval more often than your rule intended, not less. But a silently-skipped deny or ask rule is the dangerous direction: if you wrote a mid-pattern :* deny rule expecting it to block a class of commands, and it was quietly dropped from the effective rule set with no error or warning, Claude could run commands you believed were blocked. The fix adds a startup warning explaining how mid-pattern wildcards actually match, which is the tell that this rule shape had ambiguous-to-the-parser semantics worth calling out explicitly rather than just silently applying a best guess. If you have any settings-file Bash rules with a :* that isn’t the last token in the pattern, re-check them against v2.1.282’s startup warning output.
3. A Command Approved Once Running Twice After a Remote Worker Restart
The changelog entry: “Fixed a command approved on a restored permission prompt running twice when a remote session’s worker restarted.”
What failed: In a remote/cloud session (a session running on Anthropic’s infrastructure rather than your local machine — cloud sessions, Slack-triggered sessions, or similar), if the backing worker process restarted while a permission prompt was pending, Claude Code restored that prompt so you could still approve or deny it. The bug: once you approved the restored prompt, the command executed twice instead of once.
Why it bites you: Running a read-only command twice is usually harmless. Running a mutating command twice is a different story — a database migration, a git push --force, a file deletion, an API call that creates a resource (an invoice, a deployment, a support ticket) are not idempotent by default, and a silent duplicate execution triggered by infrastructure restarting mid-approval is not something a user would have any reason to expect or watch for. This is specifically a remote-session bug — local sessions don’t have a “worker restart” concept in the same way — so it matters most if you’re running Claude Code through cloud sessions, scheduled routines, or Slack-triggered work where you’re not watching a live terminal for evidence of a double run.
4. Mistyped Managed Boolean Lock Keys Silently Ignored
The changelog entry: “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.”
What failed: Managed settings support “lock” keys — boolean flags an admin sets in managed-settings.json to force a policy across every user, overriding whatever an individual sets locally. This bug: if the value written for one of these boolean lock keys was mistyped — a string "true" instead of the boolean true, a stray value that isn’t a clean boolean — the lock was silently ignored instead of either applying the intended default or erroring loudly. The admin’s managed-settings.json could contain "allowManagedPermissionRulesOnly": "true" and the lock simply wouldn’t take effect, with nothing in the UI indicating why.
Why it bites you: This is the worst kind of policy bug: it looks configured. An admin who wrote disableClaudeAiConnectors into the managed policy file and rolled it out across the org has every reason to believe it’s enforced — the file is there, the key is spelled right, it’s deployed to every machine. A YAML/JSON typing mistake (quoting a boolean, a trailing space, a copy-paste from a template that used strings for a different key) silently produced a no-op instead of the intended lockdown, and there was no startup message telling anyone the lock wasn’t active. The fix makes the lock apply even to a mistyped-but-recognizable value, and prints the key name at startup so a misconfiguration is now visible instead of silent. If you push managed policy for disableClaudeAiConnectors, allowManagedPermissionRulesOnly, or any other boolean lock key, it’s worth re-verifying on an updated client that the lock is actually showing up in claude doctor or the startup notices — don’t assume the file being deployed means the policy is enforced.
5. One Bad Nested Value Silently Disabling an Entire Managed-Settings Block
The changelog entry: “Fixed managed permissions, autoMode, worktree and attribution settings being ignored entirely when one nested value was invalid; the rest of the block now still applies.”
What failed: These four managed-settings blocks are structured objects with multiple nested keys — permissions alone covers allow/deny/ask rule lists, directory scoping, and more. Before this fix, if a single nested value anywhere inside one of these four blocks failed validation (a typo, an unsupported value, a field from a newer client version an older parser didn’t recognize), the entire block was dropped — not just the one invalid field, the whole permissions (or autoMode, worktree, attribution) object, including every other correctly-specified rule inside it.
Why it bites you: This turns a small, localized mistake into a total loss of policy for that entire category. Picture a permissions block with twenty carefully scoped deny rules and one nested value with a typo introduced in a recent edit — before this fix, all twenty rules stopped applying, not just the one with the typo, and nothing distinguished “this block is fully enforced” from “this block silently evaluated to nothing” in the client’s behavior. Combined with bug #4 above (no startup warning for a related class of mistake), an org could have shipped a managed-settings update that quietly zeroed out its entire permission policy and had no signal that anything had changed. The fix scopes the failure to just the invalid nested value, so the rest of the block — the parts that were written correctly — keeps applying. If your org edits managed permissions, autoMode, worktree, or attribution blocks by hand or via a templating pipeline, it’s worth diffing what actually applies before and after updating to confirm nothing was silently being dropped pre-v2.1.282.
6. Skills and Commands Pre-Approving Their Own Tools Around a Managed Lock
The changelog entry: “Fixed repository, user and --add-dir skills, commands and skills-directory plugin manifests pre-approving their own tools via allowed-tools under managed allowManagedPermissionRulesOnly.”
What failed: allowManagedPermissionRulesOnly is a managed lock intended to mean exactly what it says: only permission rules that come from managed policy are honored — a user or repository shouldn’t be able to grant itself extra tool access. Skills, slash commands, and plugin manifests can declare an allowed-tools frontmatter field that pre-approves specific tools for that skill or command without a runtime prompt. This bug: that self-declared allowed-tools field was still being honored even when allowManagedPermissionRulesOnly was active — meaning a skill or command shipped in the repository, a user’s own directory, or added via --add-dir could grant itself tool access the managed lock was specifically supposed to prevent.
Why it bites you: This is a direct bypass of the lock’s stated purpose. An org enabling allowManagedPermissionRulesOnly is explicitly saying “don’t let anything outside of what we’ve centrally approved grant tool access” — and a skill file checked into a repository, something any contributor with write access (or a malicious PR, if skills load from unreviewed branches) can add, was able to route around that by declaring its own allowed-tools. Combined with the fact that skills are increasingly how both official Anthropic functionality and third-party plugins ship capability, this made the lock meaningfully weaker than its name implied for any org relying on it to keep tool grants centralized. If you rely on allowManagedPermissionRulesOnly, confirm on v2.1.282+ that skills and commands outside your managed policy no longer get a free pass through their own allowed-tools declarations.
Upgrade Guidance
All six bugs are fixed as of v2.1.282 (September 24, 2026). Four of them — bugs #4 through #6, plus the effective severity of #5 — only matter if your organization uses managed settings (managed-settings.json or an MDM-deployed profile) to centrally lock down Claude Code policy. If you’re an individual developer with no managed policy in play, bugs #1 through #3 are the ones relevant to you.
Check your version:
claude --versionIf it reports anything earlier than 2.1.282, update:
claude updateIf your organization distributes Claude Code through an MDM profile or a pinned package version, coordinate that update centrally — individual developers running claude update won’t fix a fleet-wide pin, and the managed-settings bugs above (#4–#6) are specifically about policy your org controls, not something a single developer’s local update resolves on its own.
If you maintain managed-settings.json, re-audit it after updating: confirm boolean lock keys are being honored (bug #4), confirm a permissions/autoMode/worktree/attribution block with any historically-invalid nested value is now applying its other rules (bug #5), and confirm allowManagedPermissionRulesOnly is actually blocking repo- and user-level allowed-tools declarations again (bug #6).
For real allowed-tools declarations and managed-settings examples from active repositories — including how teams scope skills and commands under a lockdown policy — browse our gallery.
FAQ
Do these bugs only affect organizations using managed settings?
No — bugs #1 through #3 (the CLAUDE.md symlink escape, the skipped mid-pattern Bash rule, and the duplicate command execution after a remote worker restart) affect any user, with or without managed policy. Bugs #4 through #6 are specifically managed-settings bugs and only matter if your organization pushes policy through managed-settings.json or an MDM profile.
Were any of these six actively exploited?
Anthropic’s changelog doesn’t disclose the discovery method for any of the six entries, and none are described as actively exploited in the wild. As with the five permission-check bypasses fixed in v2.1.214 two months earlier, treat these as defense-in-depth fixes worth applying promptly rather than evidence of a specific incident.
How do I check whether my managed-settings policy was actually being enforced before this update?
There’s no retroactive audit log for policy that should have applied and silently didn’t — Claude Code doesn’t log a counterfactual for checks it never ran. The practical answer is the same as with any of these silent-enforcement-gap bugs: update to v2.1.282+ first, then re-verify your specific policy (boolean locks, permissions/autoMode/worktree/attribution blocks, and allowManagedPermissionRulesOnly) is showing up correctly in claude doctor or the startup notices, rather than trying to reconstruct what was or wasn’t enforced historically.
Is the CLAUDE.md symlink escape (bug #1) platform-specific?
Yes — the changelog entry specifically names macOS paths (/Network, the /.vol kernel-mounted path syntax, and /home). It doesn’t describe an equivalent Linux or Windows escape, though the general risk of a repo containing a symlink that resolves outside the repo is worth checking regardless of platform.