Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

A few nuances in the Claude Code managed-settings file

Open
  • Is something wrong?
#41 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
1/5
Estimated time
Under an hour
Newbie friendliness
55/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Stale
Tech stack
shell
Domain
devtools, security

Research direction

Locate the managed-settings.json deny list and review the existing rules for ~/.aws/, ~/.azure/, and Bash deletes. Reproduce the reported permission checks, then verify that the settings prevent creating, editing, and deleting files under ~/.aws/** without relying on generic Bash rules.

Written by the indexing model from the issue text.

Description

Hey, love the project.
I tested some nuances in the Claude Code config file and figured you may benefit if you haven't considered these already. Original credit: https://www.petefreitag.com/blog/claude-code-permissions/

I found Pete's blog to be only partially true, perhaps claude updated something in the last 5 months. I tried only blocking read access to .aws but blocking both read and edit to .azure, along with the other Bash denies you guys have in the settings.json. The result: I couldn't edit existing files in .aws, but I could create new ones AND I COULD DELETE FILES in .aws, whereas I could not create new files or delete them in .azure. Here's a summary of my testing and findings:

Managed Settings I tested:

    "deny": [ 
     "Bash(rm -rf *)",
      "Bash(rm -fr *)",
      … (all copied verbatim)
      "Read(~/.aws/**)",
      "Read(~/.azure/**)",
      "Edit(~/.azure/**)"
       ...
]

Output:
❯ okay now summarize everything very concisely

⏺ Security Testing Summary — managed-settings.json Permission Validation (Full Session)
We tested Read, Write, Edit, and Bash operations against credential-sensitive paths in the managed settings file, iterating through several configuration changes.

Findings:

  1. Edit is the umbrella rule — denying Edit on a path blocks Write (new files), Edit tool operations, and Bash commands on matching paths. No separate Write or Bash path-specific rules are needed.
  2. ~/.aws/** was missing Edit — the only path with only Read denied. This allowed new file writes and plain rm via Bash. Confirmed by successfully writing files and deleting ~/.aws/credentials during testing.
  3. Generic Bash deny rules don't close the gap — Bash(rm -rf *) blocks recursive deletes but plain rm on individual files bypasses it entirely. Path-specific Bash rules are not a substitute for Edit.
  4. managed-settings.json is hot-reloaded — changes take effect immediately without restarting the session. (just a fun fact)

Conclusion: The correct and minimal fix is adding "Edit(~/.aws/**)" to the deny list. The generic Bash rules added are useful hardening but insufficient on their own — Edit(~/.aws/**) is still required to fully protect that directory.

Dominant language
Shell
Stars
2.1k
Forks
164
Avg merge
3d 59m
Merged PRs (30d)
1

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from trailofbits/claude-code-config

All issues in trailofbits/claude-code-config

Similar issues

More Shell/Bash issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.