How to Make Claude Ignore Files in a Project

Claude Code does not automatically ignore any file it can reach—but there are three ways to limit what it reads or touches. You can use file exclusions (through .gitignore), tool permissions in .claude/settings.json, or advisory instructions in CLAUDE.md. Each has a different enforcement level and a different cost. Tools like fenbs keep the approved scope and the reason behind it recorded, so the boundary is not just in a config file but in a place the next session can read and understand.

Choose your method based on how hard you need the boundary to be. A CLAUDE.md instruction is easy to add and easy to override. A permission in settings.json is enforced by Claude Code's runtime. A network or filesystem restriction is enforced by the operating system.

File exclusions: .gitignore and .claudeignore

Claude Code respects .gitignore when browsing the project—files and directories that git ignores are also skipped in directory listings and file searches. This covers build artifacts, node_modules, generated files, and anything else in .gitignore.

Claude Code also supports a .claudeignore file that works the same way as .gitignore but applies only to Claude Code. Use this to exclude files that git tracks but Claude should not read: large binary assets, auto-generated source files, or anything that would fill context without helping.

Exclusions affect what Claude Code finds in searches and directory listings. They do not prevent it from reading a file if you tell it a specific path. If the boundary needs to be absolute, use a permission or a filesystem restriction.

Tool permissions in settings.json

Claude Code's .claude/settings.json can restrict file operations by path. A deny rule for a Bash or file-read tool prevents Claude Code from running that operation—even if you ask it to. This is a harder boundary than an instruction in CLAUDE.md.

{
  "permissions": {
    "deny": [
      "Write(/etc/*)",
      "Write(/home/*/.ssh/*)"
    ]
  }
}

Check Anthropic's Claude Code documentation↗ (opens in a new tab) for the exact syntax, since the pattern matching rules and available tool names change between versions. Test the rules after adding them—ask Claude Code to attempt the restricted operation and confirm it is blocked.

Advisory instructions in CLAUDE.md

A CLAUDE.md instruction like "Do not read or modify files in the secrets/ directory" tells Claude what you want. Claude Code will follow it in normal use. It is not a technical enforcement—Claude Code reads the instruction at session start and acts accordingly, but if you explicitly ask it to read a file in secrets/, it may comply.

Advisory instructions are the right tool for everyday guidance: which files are auto-generated and should not be edited by hand, which directories are owned by a different team, which test fixtures should be left alone. They communicate intent clearly and are easy to read.

For sensitive files—keys, credentials, certificates—use both a CLAUDE.md instruction and a permission in settings.json. The instruction explains the rule; the permission enforces it.

What to do about sensitive files

For files that contain credentials, private keys, or personal data, use all three layers: add the directory to .claudeignore, add a deny rule in settings.json, and add an instruction in CLAUDE.md that explains why the boundary exists. Three layers means a misconfiguration in one does not immediately expose the content.

Never ask Claude Code to read a .env file or paste credentials into the chat to "help Claude understand the environment." Set up environment variables in the shell before starting the session, or use a secrets manager. Claude Code reads from environment variables without needing to see the .env file.

Verifying the boundary

After adding exclusions, permissions, or instructions, test them. Ask Claude Code to list the files in a restricted directory, or ask it to read a specific excluded file. The response should confirm the boundary. If it reads the file anyway, the restriction is not working—check which layer the file falls into and tighten it.

Record the verified boundary in fenbs: which files are excluded, through which mechanism, and when it was last tested. If someone changes the configuration, the record shows what the boundary was before the change.

How to do this with fenbs

Connect Claude Code to fenbs and record the file access decisions for the project.

1. Create a free account and add a project in fenbs for the codebase.
2. Connect Claude Code from Integrations and follow the MCP setup guide.
3. Add a Decision for each significant file access boundary: which directories are excluded, the enforcement mechanism, who approved the configuration, and why.
4. Add a standing rule for any boundary that must always apply: "Do not read or modify files in secrets/—production credentials live there." Rules appear first in the AI context every session reads.
5. After verifying that a restriction works, mark the Decision as confirmed with the test method and date. If the restriction is ever changed, record the new decision before making the change.

fenbs does not manage your .claudeignore or settings.json files. It keeps the human decisions behind those configurations so the next session understands the boundary—not just that the restriction exists, but why.