It’s incredible how many people don’t realize this — there is no .claudeignore file. Claude Code does not natively recognize any such file.
And even your .gitignore is not as strictly respected as you might think — there are much stronger ways to reliable ignore files and avoid revealing sensitive information and wasting tokens on irrelevant file data.
Yes we already have .dockerignore and .npmignore and other kinds of .[x]ignore — so it sounds like .claudeignore is a real thing.
But it really isn’t.
But this misconception has spread across the internet — even models like Claude have recommended a .claudeignore file even though it doesn’t do anything.
And what’s the problem with .gitignore?
Claude Code does respect .gitignore for some file discovery.
It can hide ignored files from things like @-mention autocomplete. Claude Code also has settings that control whether tools like Glob respect .gitignore.
This helps keep things like node_modules, build files and other junk out of normal searches.
But .gitignore does not stop Claude from reading those files directly.
If you tell Claude to “read .env” or “check dist/output.log” it can still try to read them.
Claude can accidentally read sensitive files like API keys and production credentials. It can also read huge ignored files like logs or generated output. That can waste a lot of tokens and fill the context window with useless data.
So .gitignore can help with file discovery. It does not give you a hard security barrier.
How to actually make Claude ignore files
There are three good ways to do it.
1. Block sensitive files with .claude/settings.json
If Claude should never read a file then use its permission system.
Add rules like these to .claude/settings.json:
{
"permissions": {
"deny": [
"Read(.env*)",
"Read(*.key)",
"Read(config/secrets/**)"
]
}
}These rules can stop matching tool calls instead of simply asking Claude to behave.
This is what you want for .env files, private keys and other secrets.
Just remember that Claude can use other tools too. If you let it run Bash then a command like cat .env creates another way to read the file. For important secrets you should lock down every path that could expose them.
2. Use CLAUDE.md (or AGENTS.md) for files that waste context
Not every file needs a hard block.
Maybe you just don’t want Claude wasting tokens reading build files, logs or dependencies.
In that case add simple rules to CLAUDE.md:
## Context & File Rules
- Do not read files inside `dist/`, `build/` or `node_modules/`.
- Ignore `.log` files unless I ask you to read them.Claude Code reads CLAUDE.md as project instructions.
This works well for context management. But it’s still an instruction to Claude. It does not block the file at the tool level.
3. Use a PreToolUse hook
If you really want .claudeignore then you can make it work with a hook.
Community tools like claude-ignore use Claude Code’s PreToolUse hooks. The hook checks a file path before Claude reads it. It compares the path against patterns in .claudeignore and blocks the tool call when it finds a match.
So .claudeignore can work.
But only when you install something that actually reads and enforces it.
The easiest way to think about all of this is:
.gitignore helps with discovery. CLAUDE.md tells Claude what to avoid. permissions.deny actually blocks tool access. Hooks let you build custom ignore rules.
But .claudeignore on its own?
Don’t trust it.
That’s what makes this whole thing so interesting. People and AI made up assumptions of a feature that sounded so real that developers started using it and telling other people to use it too.
When secrets are involved you can’t rely on something just because Claude says it exists.
Make sure something actually enforces it.