Claude Code · Permissions

Deny Claude Code access to NDA / confidential folders

A copy-paste-ready recipe for keeping foundry PDKs, licensed IP libraries, and other NDA-covered material out of reach of Claude Code — using the built-in permissions.deny mechanism. No plugin, no .claudeignore needed.

1 · The three-line version

Put this in ~/.claude/settings.json to block one folder for all your sessions:

{
  "permissions": {
    "deny": ["Read(~/secret/**)"]
  }
}

Read(...) also blocks the file-reading Bash commands Claude Code recognizes (cat, head, tail, sed).

2 · A realistic multi-folder deny list

Confidential material usually lives in several places. List each one — deny rules accept gitignore-style globs. (Paths below are placeholders; substitute your own.)

{
  "permissions": {
    "deny": [
      "Read(~/proj/<foundry>_ip/**)",
      "Read(~/proj/<foundry>_pad/**)",
      "Read(~/libs/<foundry>_pdk/**)",
      "Read(~/secret/**)",

      "Edit(~/proj/<foundry>_ip/**)",
      "Edit(~/libs/<foundry>_pdk/**)"
    ]
  }
}

Add the matching Edit(...) lines if you also want to prevent modification, not just reading.

3 · Pattern syntax cheat-sheet

Pattern	Resolves to
`path` / `./path`	relative to the current working directory
`~/path`	your home directory
`//abs/path`	absolute filesystem path
`*`	matches within a single path segment
`**`	matches recursively across directories

Handy detail: for deny rules, a single-segment pattern like Read(secret/**) matches a secret/ folder at any depth — so it also catches nested copies.

4 · Precedence — deny always wins

Rules are evaluated deny → ask → allow. A deny at any settings scope blocks the path even if another scope allows it. You can't accidentally re-open a denied folder from a project file.

5 · Where to put it (and how to enforce it for a team)

File	Scope
`~/.claude/settings.json`	just you, every project
`<project>/.claude/settings.json`	committed to git — shared with the team
`<project>/.claude/settings.local.json`	personal, gitignored
`/etc/claude-code/managed-settings.json`	managed policy — users cannot override

Make it unbreakable. To stop users from lifting the rule, put the deny in managed settings and add "allowManagedPermissionRulesOnly": true — then only the managed permissions rules apply.

6 · Verify it works

Start a fresh Claude Code session (settings load at startup) and ask it to read a file under a denied path. It should refuse rather than show the contents. Deny changes are not retroactive within an already-running session — restart first.

7 · The one gap to know about

Read(...) governs Claude's own file tools and the file-reading Bash commands it recognizes. It does not stop an arbitrary subprocess — a Python or OCEAN script that opens the file itself — from reading it. For an OS-level guarantee across every process, enable Claude Code's sandbox and use filesystem.denyRead / filesystem.denyWrite.

TL;DR — permissions.deny with Read(~/path/**) rules is the shared, built-in way to fence Claude Code out of confidential folders. Commit it in the project for a team; use managed settings to make it non-overridable.

Applied example: a real TSMC PDK AI-access policy built with these rules — which foundry folders are NDA and what an AI assistant can and can't do for the synthesis / STA flow. (Private repo — the link resolves only for authorized users.)