
Image: Apiiro
Why it mattersA developer who clicked "Yes, and don't ask again" may have committed a secret to a public repo. The file needs a global gitignore entry today.
Apiiro searched public GitHub on 5 November 2026. The firm looked for one file: .claude/settings.local.json. It found 104,185 copies. 1,122 of those files held a real secret, Apiiro says. The firm also checked the file's history, a shared settings file and agent transcripts. The total across all of those came to 2,539 real secrets in 1,994 repos.
The 1,122 files between them held 1,379 distinct secrets. Apiiro counts 636 provider API keys. The listed providers are OpenAI, Anthropic, AWS, Supabase, Stripe and Slack. The other 743 are passwords or tokens next to public hosts. The median repo had committed the file 217 days before the search. 118 repos had committed it over a year ago.
How the secret gets into the file
Claude Code asks for permission before it runs a shell command. The developer sees a prompt. One option is "Yes, and don't ask again". If the developer picks it, Claude Code runs the command. It also writes a permission rule to .claude/settings.local.json in the project folder. The rule is the command string itself. So if the command was curl -H "Authorization: Bearer sk-ant-...", that Bearer token is now a line in a JSON file inside the repo.
Claude Code adds .claude/settings.local.json to the user's global gitignore when it is installed. That rule can miss the file in several cases. A developer clones the repo on a fresh machine. Another developer uses a different git setup. A new repo starts before the gitignore rule is in place. In each case the file gets committed. Apiiro says Claude itself co-authored the commit that added the file in 539 of the 1,105 affected repos they inspected.
Anthropic's response
Boris Cherny from the Claude Code team posted on the Hacker News thread about Apiiro's post. He wrote that .claude/settings.local.json "is meant to stay local". On secret scrubbing, Cherny wrote that Claude Code has not done it. He said the team is now looking into what it can do to prevent this. He recommended Auto mode instead. In that mode, a classifier model judges each command and only asks about a risky one. He also suggested teams turn on GitHub's own secret scanning.
What to do today
Apiiro's recommendation is to stop typing secrets into commands at all. The firm says to reference a variable from a secrets manager instead. The saved permission rule then reads $DB_URL rather than the password. A second step: add .claude/settings.local.json to the repo-level .gitignore too, not only the global one. That way a clone on a fresh machine still ignores it.
Any team that lets its developers use Claude Code can run Apiiro's search on its own code. GitHub's code search accepts the same path:.claude/settings.local.json filter on private repos. A team that finds its own file there can rotate the keys before the next audit does. Secret scrubbing is not yet part of Claude Code itself. For now the team that uses it has to do that work.
Source
This item was written by an AI system from the linked source. Reveneau is responsible for what it publishes.
Get AI News in your inbox
New developer tools, model and agent releases, and how teams are actually using them to release software. Short, and only when there is something worth reading.