Does .claudeignore work? I tested it on lockfiles in Claude Code

Does .claudeignore work in Claude Code? No. I put package-lock.json in a .claudeignore file and asked Claude Code four questions that only the lockfile can answer, three times each: Claude read lockfile text in 12 of 12 runs, the same as with no file. Claude Code 2.1.306 never opens the file, and its permissions docs now say so: “If your project has a .claudeignore file, it has no effect, so move its entries into Read deny rules.” I tested that advice as well. A deny rule did keep the lockfile out, every time. It also left Claude able to answer 0 of 12 questions, and in 6 of them Claude told me the project had no lockfile at all.

Lockfiles are a classic “keep this out of the context” file. In an earlier post on counting a codebase’s tokens, one uv.lock was 67% of a small Python repo. So I measured three things: what a lockfile costs in Claude tokens, which of the popular ways to hide it actually work, and what hiding it costs you in answers.

How many tokens does a lockfile cost Claude?

I counted each file the same way as in the codebase post: run claude -p once with the file and once without, and subtract the reported input tokens. No API key is needed, and Claude Opus 4.7 and later (including Haiku, Sonnet and Opus 5.5) share one tokenizer. The first three rows lock the same package.json (10 direct dependencies, 288 packages) with three package managers; the rest are lockfiles from well-known repos.

Lockfile	Size	Claude tokens	o200k (GPT-5)	chars / 4
package-lock.json (288 packages)	128 KB	73,135	52,351	32,771
yarn.lock (same packages)	88 KB	61,605	44,269	22,511
pnpm-lock.yaml (same packages)	73 KB	50,297	36,467	18,780
uv.lock (Flask)	273 KB	160,388	130,291	69,799
poetry.lock (Poetry)	253 KB	155,499	122,957	64,704
go.sum (GitHub CLI)	58 KB	45,612	31,961	14,863
composer.lock (Composer)	91 KB	31,275	22,398	23,271
Gemfile.lock (Rails)	43 KB	27,022	21,775	10,942
Cargo.lock (ripgrep)	13 KB	7,157	5,024	3,387

Two things stand out. The “characters divided by 4” rule undercounts lockfiles badly: 2.2 times for package-lock.json and 3.1 times for go.sum, which is mostly hashes. And the same dependency tree costs 31% fewer tokens as pnpm-lock.yaml than as package-lock.json.

A 73,000-token file would hurt if Claude read it whole. As the runs below show, it almost never does.

How I tested it

The test project is a small Express API: 6 source files, a package.json with 10 direct dependencies and a real 131 KB package-lock.json made with npm install --package-lock-only. There is no node_modules, as in a fresh clone, so the lockfile is the only record of what gets installed.

Four questions need the lockfile:

1. Which exact version of express is installed? (4.22.3; package.json only says ^4.21.0)
2. How many versions of debug are in the tree, and which packages pull in the older one? (4.4.3 and 2.6.9, from express, body-parser, finalhandler and send)
3. Is the project affected by CVE-2024-47764 in cookie, fixed in 0.7.0? (No, it ships 0.7.2)
4. Which version of vite does vitest bring in? (5.4.21)

Two more are plain code questions (where the JWT is checked, and adding a /health route), to see whether hiding the lockfile changes anything for everyday work.

Each run copied the project to a fresh temporary folder, applied one condition, and asked one question with claude -p --output-format stream-json, Sonnet 5.5, Read, Grep, Glob, Edit and Write allowed. Bash was not allowed, but headless Claude Code runs commands it judges read-only, like ls and grep, without asking, so Bash was part of the test. The conditions:

• none: nothing.
• claudeignore: a .claudeignore file listing package-lock.json, yarn.lock and pnpm-lock.yaml.
• dotignore: the same list in .ignore, the file ripgrep reads. Claude Code’s Grep and Glob tools run on ripgrep, so I expected this one to do something.
• deny: Read(./package-lock.json) and Read(**/package-lock.json) (and the same for the other two) in permissions.deny in .claude/settings.json.
• instruction: “Never read lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml) in this project. They are large generated files; use package.json instead.” I passed it with --append-system-prompt because the runs switch off CLAUDE.md loading to keep my own files out. It stands in for a CLAUDE.md rule.
• deny + npm ls: the deny rules, plus --allowedTools "Bash(npm ls:*)" and one sentence telling Claude to use npm ls <name> --package-lock-only.

Six conditions, six questions, three runs each, plus a failed first batch of the last condition (more on that below): 120 runs in 23 minutes of run time, USD 3.74 at API prices, run on a subscription. A script logged every tool call and counted the lockfile text that came back in each tool result. I also read all 120 answers.

Results

Condition	Runs where lockfile text reached Claude	Right answers	Mean cost per run
none	12/12	12/12	$0.040
.claudeignore	12/12	12/12	$0.035
.ignore	12/12	12/12	$0.029
permissions.deny	0/12	0/12	$0.036
instruction	1/12	1/12	$0.034
deny + npm ls	0/12	12/12	$0.020

The code questions came out the same everywhere: 6 of 6 right in every condition.

Does .claudeignore work in Claude Code?

It does nothing. The string claudeignore does not appear anywhere in the Claude Code 2.1.306 executable, and the runs agree: the same 12 of 12 lockfile reads as with no file, through the same grep -A3 '"node_modules/express"' package-lock.json commands. Claude saw the .claudeignore name in ls or git ls-files output in 6 of the 18 runs and never opened it.

The tip keeps circulating partly because Claude itself sometimes suggests the file, as one closed issue describes. If you have one, it is a note to humans.

Does .ignore hide files from Claude Code?

Partly. Claude Code’s Grep tool runs ripgrep, which honors .ignore, so a search across the whole repo stopped returning lockfile lines. In the JWT question with no ignore file, a broad jwt|jsonwebtoken search pulled in a few lockfile lines in 3 of 3 runs; with .ignore, 0 of 3. But when Claude names the file, ripgrep searches it anyway, and cat or grep in Bash don’t know about .ignore. All 12 lockfile questions still read it and got the right answer.

What does a permissions.deny Read rule block?

Everything I saw Claude try. The Read tool was refused, Grep on the file got “Permission to read … has been denied”, and so did Bash commands that name the file:

Permission to use Bash with command grep -n -A3 '"node_modules/express"' package-lock.json has been denied.

Without the rule, the same kind of command ran without a prompt. The docs say deny rules cover file commands Claude Code recognizes in Bash, but not a recursive grep of the folder that holds the file. No run tried that route, so I can’t confirm the gap.

The problem is how the rule hides the file. Glob filters denied paths out of its results, so *lock* came back “No files found”, and a Grep with a lockfile glob came back “No matches found” rather than an error. Claude believed it. In 6 of the 12 runs it told me the project had no lockfile:

I can’t give you an exact installed version, because nothing is installed or locked in this project. There’s no node_modules and no lockfile (package-lock.json, pnpm-lock.yaml or yarn.lock).

The lockfile was right there, and ls -a showed it in other runs. To its credit, Claude never made up an exact version. The 12 answers either said it couldn’t check or gave a hedged range from memory (“So you’d get some Vite 5.x release”). Deny runs also took the most steps: 6 tool calls at the median against 3 with no rule, as Claude tried route after route.

Does a “don’t read lockfiles” instruction work?

Mostly. Claude followed it in 11 of 12 runs and then declined to answer, saying the version was in a file it had been told not to read. In the twelfth run it grepped package-lock.json anyway and answered correctly. So an instruction is a preference, not a guarantee, which is what the long-running issue on CLAUDE.md compliance argues too.

How much does Claude actually read from a lockfile?

Very little, when it is allowed. Across the 36 runs where nothing blocked the file, the median lockfile text that reached Claude was about 1 KB: Claude greps for the one entry it needs. 34 of 36 runs took under 5 KB.

The exception shows what the fear is about. In one run Claude Code’s bundled ripgrep failed to start (EACCES: permission denied, posix_spawn 'rg', seen in 2 of the 120 runs), so Claude fell back to the Read tool on the whole lockfile. Read returned the first 1,097 lines, Claude read another 250 further down, and the run used 134,137 input tokens and cost $0.151, nearly four times the $0.040 average.

So the token argument for hiding lockfiles is weaker than the tips suggest. On this project, reading the lockfile was the cheap way to the right answer.

What I’d use instead

Block the raw file, and give Claude a better tool for the same question. With deny rules plus npm ls allowed, Claude ran one command, such as npm ls cookie --package-lock-only, and answered all 12 questions right. It needed a median of 2 turns against 4, and cost $0.020 per run against $0.040 for grepping the lockfile:

{
  "permissions": {
    "deny": ["Read(./package-lock.json)", "Read(**/package-lock.json)"]
  }
}

claude -p "Is this project affected by CVE-2024-47764?" \
  --allowedTools "Bash(npm ls:*)" \
  --append-system-prompt "Lockfiles are blocked. For installed versions run npm ls <name> --package-lock-only."

npm ls --package-lock-only reads the lockfile without node_modules. pnpm (pnpm why) and yarn (yarn why) have similar commands, which I did not test.

What broke

My first batch of that last condition failed, 0 of 8. I had put "allow": ["Bash(npm ls:*)"] in the project’s .claude/settings.json, next to the deny rules, and every npm ls came back “This command requires approval”. A manual run in the same setup printed the reason to stderr:

Ignoring 1 permissions.allow entry from .claude/settings.json: this workspace has not been trusted.

Project allow rules only apply after you accept the trust dialog for that folder, and claude -p never shows the dialog. Deny rules from the same file applied at once. The settings docs describe this; I found it by failing. For headless runs in CI or a fresh checkout, pass allow rules with --allowedTools or put them in an untracked .claude/settings.local.json. I checked both by hand, and the 12 runs in the results table pass the rule with --allowedTools.

Limits

• One small npm project, one model (Sonnet 5.5), three runs per question. A monorepo with a 2 MB lockfile could push Claude toward bigger reads.
• Headless runs only. In an interactive session Claude would ask you before a blocked command, and you could approve it.
• The instruction went in through the system prompt, not a real CLAUDE.md, so the comparison with a project file is close but not exact.
• The lockfile is not in the repo: the projects repo’s push guard reads version strings that start with 10. as private IP addresses. make-fixture.sh recreates it and prints the checksum of the one I measured.

The full results, every answer and the scripts are in the project folder. If you pack whole repos for Claude, the Repomix compress test covers the other side of this: what you lose when the context gets smaller.