Claude Code 2.1.269: a scoped permission rule, and your CLAUDE.md wins on attribution

Claude Code 2.1.269 shipped on September 11, 2026, a day after 2.1.268, which the previous digest covered. Two fixes change what Claude Code enforces on your behalf without you asking for it: a permission rule that leaked past its own settings file, and an attribution reminder that overrode your own CLAUDE.md instructions. Alongside those, skills synced from claude.ai get a new name, and a new command lets you test a plugin without a human re-checking every change.

A deny rule that leaked beyond its own settings file

A permission rule can come from several sources at once: user settings, project settings, local settings, or an organization's managed policy. The permissions doc covers this directly, and the /permissions dialog lists each rule alongside the settings.json file it came from, precisely because these sources stack and you need to trace where a decision originated.

2.1.269 fixes a bug in deny and ask rules that start with !, a negation syntax inherited from the gitignore patterns those rules use, meant to carve a path back out of another rule's reach. The problem: that negation could apply beyond the settings source that wrote it, meaning it could cancel a rule set in a different source, potentially including a stricter rule coming from a managed policy. A negation written in a local settings file has no business weakening what an organization enforces higher up the precedence order described in the settings doc. That's fixed now: a ! rule only applies within its own source. A bare ! with nothing after it is ignored instead of being treated as a valid negation.

Your CLAUDE.md now wins on commit attribution

The second default-behavior fix affects nearly anyone who commits code through Claude Code: the built-in reminder that adds attribution lines (Co-Authored-By, the Claude Code mention) to commits and pull requests used to override a CLAUDE.md or memory rule that explicitly asked for no attribution. Writing it plainly in your CLAUDE.md wasn't enough, the reminder still won.

The memory doc states the general principle: CLAUDE.md is context Claude tries to follow, not enforced configuration the way a permission rule is. 2.1.269 brings attribution in line with that principle: an instruction against attribution in your CLAUDE.md or memory is now respected. The one exception makes sense: an attribution line set by an organization's managed settings still applies, whatever your personal CLAUDE.md says.

Synced skills get a new name

Skills you configure on claude.ai that sync into a cloud Claude Code session now invoke as anthropic-skills:<name> instead of the bare name used before. It's not an arbitrary change: it's the same namespacing already used for plugin skills, documented on the skills page, where a plugin skill is called as /plugin-name:skill-name so a generic name doesn't collide with another one. Claude Desktop already used this convention; 2.1.269 brings cloud sessions in line.

The bare name still works as long as nothing else claims it, exactly like an ordinary plugin skill. If you're used to invoking a synced skill by its bare name in a script or a routine, that keeps working absent a collision, but the full form is now the stable way to guarantee you're calling the one you mean.

claude plugin eval: score a plugin without a human re-check

A new command, claude plugin eval, runs a plugin's test suite, a set of realistic prompts paired with pass/fail graders, and produces a reproducible score in JSON plus an HTML report. The plugin evals doc draws a clear line between an eval and what already existed: claude plugin validate checks that a plugin's structure and syntax are correct, while an eval checks its actual behavior, how often Claude reaches for it and gets the right result, including a comparison against a session with no plugin at all.

In practice, that means you can wire a plugin's score into CI and catch a regression the moment you change the plugin or a new model ships, instead of finding out in production. If you distribute a plugin to a team or on a marketplace, this fills the gap between "it loads without error" and "it actually does what it's supposed to."

Everything else

• /output-style [name] lists and switches output styles directly, including over Remote Control and in cloud or headless sessions.
• Remote and headless sessions no longer show "waiting for your input" while background agents are still running; set CLAUDE_CODE_BG_TASKS_REPORT_RUNNING=0 to restore the old display if you prefer it.
• permission_denials in --output-format stream-json no longer omits Read, Edit and Write calls blocked by a path-scoped deny rule, closing a blind spot for anyone auditing those denials by script.
• Edit() deny rules and the write-path check now apply to the file a Bash tee command writes, and a Bash(tee:*) allow rule no longer covers destinations outside the working directories.
• The Bash tool result can now carry a diff of the files a command changed when the Bash tool is the one handling the edit, via the bashEditDiffEnabled setting.
• Two prompt-cache fixes: the cache is no longer partially invalidated on the turn after a response was cut off at the token limit and auto-resumed, and resuming a session right after interrupting Claude mid-thought no longer changes how earlier context gets re-sent.
• CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS raises the Workflow tool's concurrent-agent cap, useful for fan-outs bottlenecked by inference speed rather than anything else.
• VS Code gets a Hooks dialog and a Permission rules dialog in the command menu, to list, add, edit or remove hooks and permission rules without hand-editing settings.json.
• Claude Code on the web lets you take back a queued message in a cloud session before Claude reads it, by removing it from the queue or pressing Esc or Up.

What to take away

If you're a solo user on a regular claude.ai account, the line that affects you most directly is the attribution one: if you'd already written in your CLAUDE.md or memory that you didn't want Co-Authored-By lines on your commits and it wasn't working, it should from this version on. The ! rule fix mainly matters for setups that stack multiple settings sources, typically a team or a managed policy. Renaming synced skills breaks nothing as long as there's no name collision, and claude plugin eval is for plugin authors who want a score instead of a gut feeling about what their plugin actually contributes.