Ask before editing Claude Code's settings files #213

Closed
opened 2026-11-10 20:39:32 +01:00 by motoko · 0 comments
Collaborator

Defect

.claude/settings.json holds no ask rule on Claude Code's own settings
files, so in bypassPermissions mode an agent edits
.claude/settings.json or .claude/settings.local.json without asking.
Those files hold the Read deny rules on secret files, the sandbox, and
the credential variables it unsets, so one unasked edit can turn off the
secret protection the README's Hooks and settings section describes.

Seen at 99fc8652bb5e4431fece00cab512d29469909f34, in a repository
adopted from it, with Claude Code in bypassPermissions mode: the file
tools edited and then rewrote .claude/settings.local.json with no
prompt.

Evidence

Claude Code's permission modes
page says writes to protected paths such as .claude "are never
auto-approved except in bypassPermissions mode", and that no mode,
bypassPermissions included, auto-approves "tools matched by an
explicit ask rule". The permissions
page says Edit rules apply to every built-in tool that edits files,
Write included.

So Manual and acceptEdits already prompt, and bypassPermissions is
the one mode where only an explicit ask rule makes the edit prompt.

Scenario

A developer runs a session in bypassPermissions mode. An instruction
injected into what the agent reads, or a mistaken step, has it add
"sandbox": {"enabled": false} or a Read allow to
.claude/settings.local.json; the next command reads a nested .env
and nothing asked first.

Smallest fix

Add an ask list to permissions in .claude/settings.json:

"ask": [
  "Edit(/.claude/settings.json)",
  "Edit(/.claude/settings.local.json)"
]

The anchored form resolves from the project root, and the README's Hooks
and settings section would name the prompt among what the file keeps.
A Bash write that runs outside the sandbox stays uncovered, since a rule
cannot match every shell form; the sandbox already refuses such writes
inside it.

## Defect `.claude/settings.json` holds no `ask` rule on Claude Code's own settings files, so in `bypassPermissions` mode an agent edits `.claude/settings.json` or `.claude/settings.local.json` without asking. Those files hold the `Read` deny rules on secret files, the sandbox, and the credential variables it unsets, so one unasked edit can turn off the secret protection the README's Hooks and settings section describes. Seen at `99fc8652bb5e4431fece00cab512d29469909f34`, in a repository adopted from it, with Claude Code in `bypassPermissions` mode: the file tools edited and then rewrote `.claude/settings.local.json` with no prompt. ## Evidence Claude Code's [permission modes](https://code.claude.com/docs/en/permission-modes) page says writes to protected paths such as `.claude` "are never auto-approved except in `bypassPermissions` mode", and that no mode, `bypassPermissions` included, auto-approves "tools matched by an explicit ask rule". The [permissions](https://code.claude.com/docs/en/permissions) page says `Edit` rules apply to every built-in tool that edits files, `Write` included. So Manual and `acceptEdits` already prompt, and `bypassPermissions` is the one mode where only an explicit `ask` rule makes the edit prompt. ## Scenario A developer runs a session in `bypassPermissions` mode. An instruction injected into what the agent reads, or a mistaken step, has it add `"sandbox": {"enabled": false}` or a `Read` allow to `.claude/settings.local.json`; the next command reads a nested `.env` and nothing asked first. ## Smallest fix Add an `ask` list to `permissions` in `.claude/settings.json`: ```json "ask": [ "Edit(/.claude/settings.json)", "Edit(/.claude/settings.local.json)" ] ``` The anchored form resolves from the project root, and the README's Hooks and settings section would name the prompt among what the file keeps. A Bash write that runs outside the sandbox stays uncovered, since a rule cannot match every shell form; the sandbox already refuses such writes inside it.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
claudiomaradonna/agent-foundry#213
No description provided.