Ask before editing Claude Code's settings files #213
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Defect
.claude/settings.jsonholds noaskrule on Claude Code's own settingsfiles, so in
bypassPermissionsmode an agent edits.claude/settings.jsonor.claude/settings.local.jsonwithout asking.Those files hold the
Readdeny rules on secret files, the sandbox, andthe 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 repositoryadopted from it, with Claude Code in
bypassPermissionsmode: the filetools edited and then rewrote
.claude/settings.local.jsonwith noprompt.
Evidence
Claude Code's permission modes
page says writes to protected paths such as
.claude"are neverauto-approved except in
bypassPermissionsmode", and that no mode,bypassPermissionsincluded, auto-approves "tools matched by anexplicit ask rule". The permissions
page says
Editrules apply to every built-in tool that edits files,Writeincluded.So Manual and
acceptEditsalready prompt, andbypassPermissionsisthe one mode where only an explicit
askrule makes the edit prompt.Scenario
A developer runs a session in
bypassPermissionsmode. An instructioninjected into what the agent reads, or a mistaken step, has it add
"sandbox": {"enabled": false}or aReadallow to.claude/settings.local.json; the next command reads a nested.envand nothing asked first.
Smallest fix
Add an
asklist topermissionsin.claude/settings.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.