If you build software for clients, or run an in-house development team, check your repositories today. Researchers at Apiiro found 1,122 public copies of a Claude Code settings file that hold at least one password, token or key. This Claude Code secrets leak is not a UK company breach. It is a habit that can quietly turn a private secret into a public one.
The Hacker News reported on 7 November 2026 that Apiiro looked at the file .claude/settings.local.json on public GitHub. When a user picks “Yes, and don’t ask again”, Claude Code can save the approved command in that file. If the command contained a password, the password is saved too, in plain text. Apiiro found 104,185 copies of the file, and about 1.1% (1,122) held at least one secret. Those included 379 database passwords, 43 SSH logins and 23 AWS keys. Apiiro did not test whether the secrets still work, but one notified company confirmed its key had been live. Deleting the file does not fix it, because older versions stay in git history and in forks. Source: The Hacker News
Nobody hacked anything here. A developer typed a database password into a command to test a connection. They clicked “don’t ask again” to stop the interruptions. The tool saved the command. A later commit pushed it to a public repository.
That chain is ordinary, and it fits the way agencies, freelancers and small in-house teams work. You move fast. You test against real databases. You reuse repositories and hand them to clients, contractors and forks.
Two details make it worse. First, the usual safety net is thin. Claude Code adds the file to a global git ignore on one computer, but The Hacker News says it never adds it to the project’s own .gitignore. A new clone on another machine, or a file committed earlier, gets no protection. Second, scanners miss it. Of the 1,122 files with a secret, gitleaks flagged 564 and TruffleHog 643, and neither flagged 215. A password after PGPASSWORD= or mysql -p looks like an ordinary word, not a key format.
On responsibility, the sources disagree. Apiiro says a Claude-co-authored commit changed the file in 539 of 1,105 repositories it traced. A Claude Code team member, as relayed by Developers Digest from a Hacker News thread, said the leaked files were created by hand and checked in, and that the team is looking at preventing this. Developers Digest could not verify either side’s numbers. You do not need to settle that argument to act. Your exposure is the same either way.
If you only treat the leak as a code problem, you will miss the real one. The question is what an outsider could now log in to.
.claude/settings.local.json and .claude/settings.json.git rm --cached .claude/settings.local.json and add it to each repository’s own .gitignore.Rotating the secrets you know about is the easy part. For the wider picture, browse our credentials and exposure guides, or run the free web vulnerability scan on your public site. The harder part is knowing what of yours is already exposed beyond your own systems. Wolfcore’s Breachy is our breach exposure monitoring service, built for exactly that question. It gives you a clearer picture of where your business is exposed, so you can fix the right things first.
Ruben Selby Founder and Lead Security Consultant, Wolfcore
The Hacker News names .claude/settings.local.json, saved when a user picks “Yes, and don’t ask again”.
No. Older versions stay in git history and in forks, so rotate the secrets first.
The sources name no UK business. This is a habit that can put a secret into a public GitHub repository.
See also our recent post on device code phishing.