Settings-file edit guard adds desktop-app, symlink and…

Settings-file edit guard adds desktop-app, symlink and managed-policy refusal messages, but the path is off in this build

Refusal messages for settings-file edits via the desktop app, symlinks or managed policy exist but cannot run in this build

EntryKind: in v2.1.281, 23 Sep 26

ChangesSection of the release

What

New code picks a reason for refusing an edit to a Claude Code settings file and sends back a matching message:

"card": in the Claude desktop app, the edit applies only if you approve it on its permission card.
"linked": the path reaches a settings file through a symbolic link, a shortcut that points to another file.
"policy": the path is, or may be, a managed-settings.json file or the file given with --settings.
"review": the existing staging for /settings-review.

Every message tells the model not to try again. This code cannot run in this build. It needs an internal switch set to true while running and a helper that always answers no.

Why

For now nothing changes. The messages show the edits that are meant to be refused: edits through a link, edits to policy-controlled files, and desktop-app edits you have not approved.

How sure we are

One source agreesOne thing we can check says the same as this entry.

Anthropic's release notes agreeAdded "attribution": false in settings.json to hide all commit and PR attribution; older CLI versions skip a settings file that holds it, so…

See this entry in the whole of v2.1.281 →

The build it came inv2.1.281

23 Sep 2026 · 1,065 entries, this one is #708.

Use it now39
You'll notice261
Nothing to try yet26
Under the hood217

Either side of it

v2.1.280Older
v2.1.282Newer

Open the release →

Names in this entry

cli--settings
Path to a settings JSON file or an inline JSON string. Values you set here override the same keys in your settings.json files for this session. Keys you omit keep their file-based values. The file must be a regular file no larger than 2 MiB. See settings precedence
slash/settings-review
Claude Code now blocks direct writes to the settings-review staging store

Anthropic's note

Upstream's own release notes for v2.1.281 name something this entry names, so the two are probably about the same change. Probably: the pairing is made on a shared name rather than on the words around it.

Added "attribution": false in settings.json to hide all commit and PR attribution; older CLI versions skip a settings file that holds it, so keep the object form in files shared across versions

Is this right?