If you use Claude Code and you've ever clicked "Yes, and don't ask again" on a command with a password in it, that password is probably sitting in a file in your project. This week a security firm showed how often those files end up public.
Apiiro searched public GitHub repositories for Claude Code's local settings file. According to iTnews, it found 1,122 copies holding at least one real secret, with 1,379 distinct secrets between them. That included 379 database passwords, 122 Supabase service-role keys, 43 SSH logins and 23 AWS keys. Counting older versions of the file, shared settings files and saved chat transcripts, the total came to 2,539 secrets across 1,994 repositories.
Apiiro didn't test whether the credentials still worked. One organisation it contacted confirmed its key was live. That's enough for me.
What the button actually does
Claude Code asks before it runs a shell command. Anthropic's own settings docs explain what happens when you approve one for good: Claude Code "saves that approval as an allow rule in .claude/settings.local.json".
The rule is the command you approved. So if that command was a database login with the password on the end, or a curl call with a bearer token in the header, the secret is now written into a JSON file inside your project folder. Not encrypted, not masked. Just there, in plain text, next to your code.
Anthropic has thought about git. The docs say Claude Code adds the file to your global git excludes when it creates it, and that if you create the file by hand you need to add it to .gitignore yourself. So how do over a thousand of them end up on GitHub?
Why the ignore rule isn't the whole answer
I'm not going to guess how each one got there. But there are some very ordinary ways a file you thought was ignored ends up committed or shared, and they're worth knowing about.
- The ignore rule lives on your machine, not in the repo. A global excludes file only protects commits made from that one laptop. A colleague, a new machine, a build server or a different git client doesn't know about it.
- Forced adds. git add -f, or a tool that stages a folder regardless of ignore rules, will take it without complaint.
- Copying the project. Zip the folder for a contractor, or drag it into a new repo through a web page, and git's ignore rules don't come into it at all.
- The shared file. Teams commit .claude/settings.json on purpose so everyone gets the same setup. The docs note that in the VS Code extension the approval card can save the rule there instead. Anything approved into that file goes wherever the repo goes.
And once a secret is in git history, deleting the file doesn't get rid of it. It's still in the older commits, in every clone and in every fork.
What to do today
For most projects this is a ten minute job. If you use Claude Code, or anyone who has worked on your code does, go through these.
- Look. Open .claude/settings.local.json and .claude/settings.json in each project and read the allow list. Anything with a password, key or token in it is a problem, committed or not.
- Check git. Run git log --all -- .claude/ in each repo. If it returns anything, files from that folder have been committed at some point.
- Rotate first, tidy second. If a real secret was ever committed, change it. Database password, API key, SSH login, the lot. Apiiro's advice is the same: rotate everything the file ever held before you clean up.
- Put the rule in the repo. Add .claude/settings.local.json to the project's own .gitignore so the protection travels with the code. If it's already tracked, git rm --cached removes it from the index without deleting your copy.
- Stop typing secrets into commands. Keep them in environment variables or a config file outside the project and refer to them by name. Then the saved rule says $DB_PASSWORD, not the password.
- Approve patterns, not exact lines. The permissions docs say a * in a Bash rule "matches any text, including spaces", so one rule like Bash(npm run *) can cover a family of commands.
- Turn on secret scanning. Most git hosts can flag or block pushes containing known key formats. Treat it as a safety net, not the plan. iTnews reports that 215 of the 1,122 files were missed by both gitleaks and TruffleHog.
I've written up the wider job of getting keys out of code, and why rotation comes first, in a plain-English guide: API keys in your code: why it matters and how to fix it. If any of those keys were for AI services, my three server checks for stolen AI keys are worth a look, and so is our piece on what a stolen AI key can cost.
The bigger point
I like Claude Code. We use AI tools to build software and we're open about how we use them. This isn't a reason to stop.
It is a good reminder that coding agents leave things behind. Settings files, chat transcripts, logs, little scripts written to test one thing. They sit in the project folder next to your code, and they can hold whatever was typed into them. Most people never open that folder.
If your app was built quickly with AI, by you or by someone else, it's worth assuming there's some of this in there until you've checked. Not because anyone was careless. The tools just make it very easy, and nobody tells you to look.
That's the sort of thing a second pair of eyes is for. Our code audit is £250 + VAT and covers one system: the code and its security, the server and backups, and the database, with a written report within five working days. If you'd rather someone kept an eye on it all the time, Look after it starts from £355 a month + VAT.
If you're not sure what's sitting in your project folder, get in touch and we'll have a look.
Cheers, Rob
