Security firm Apiiro says Claude Code's "Yes, and don't ask again" button has put passwords and API keys into public GitHub repositories. The secrets were typed into shell commands that developers approved, and Claude Code saved those commands word for word in a project settings file. Apiiro found at least one secret in 1,122 public copies of that file, according to The Hacker News, which reported the research on November 7.
The file is .claude/settings.local.json. Apiiro did not test whether the secrets still work, but one company it notified confirmed its key had been live, The Hacker News reports. Boris Cherny of the Claude Code team replied on Hacker News that "Historically Claude Code has not done secret scrubbing" and that the team is "looking into what we can do to prevent this."
How a password ends up in the file
By default, Claude Code asks before it runs most shell commands. Its permissions documentation says that when you pick "Yes, and don't ask again" on a Bash command, the approval is saved permanently as a rule in .claude/settings.local.json at the root of the git repository. Later sessions run matching commands without asking.
Sometimes that rule is a pattern, such as npm test *. Sometimes it is one exact command. When it is the exact command, anything typed into it is saved too, in plain text. The Hacker News gives the example of a password placed after PGPASSWORD=, sshpass -p or mysql -p. Apiiro says it reproduced the behavior with Opus 5.5 and Fable 5.1, the latest models.
Claude Code does try to keep the file out of git. Per its settings documentation, the first time it writes the file in a repository, it adds the file to the user's global git excludes. Apiiro's point, as The Hacker News relays it, is that this protection lives in one person's git settings on one computer. It does nothing for a file that was already committed. And because Claude Code does not add the file to the project's own .gitignore, the protection does not travel with the project.
Cherny's reading is different. He wrote that the file "is meant to stay local" and that "We automatically gitignore it when Claude creates the file, so in this case the files were manually created and checked in." Apiiro's data complicates that: in 539 of the 1,105 repositories it traced, a commit listing Claude as a co-author changed the file. The researchers take that to mean Claude often commits the file itself.
What Apiiro counted
All figures below come from Apiiro's research as reported by The Hacker News.
- 104,185 public copies of
.claude/settings.local.json, in 103,617 repositories - 1,122 copies (about 1.1%) hold at least one secret, 1,379 distinct secrets in total
- 379 database passwords, 43 SSH logins for public servers, 42 tokens for GitHub, GitLab and npm, and 23 AWS keys
- 63 organizations among the owners, mostly software companies
- 734 more secrets in older versions of the file across 509 repositories, and 298 of 76,011 copies of the shared
.claude/settings.jsonholding secrets
Counting git history, the shared settings file and saved agent chat logs, Apiiro's total is 2,539 secrets across 1,994 repositories. That is why some outlets report 2,539 and others 1,122. The two numbers count different things.
A value counted as a secret only if it matched a known key format, or if a password or token sat next to a public server address, and an AI reviewer also agreed. When Apiiro checked, every file with a secret was still on its repository's default branch, The Hacker News reports, and in half of those repositories it had been there for at least 217 days.
Common scanners miss many of these. Apiiro ran gitleaks and TruffleHog over every copy, without the tools' verification step. Of the 1,122 files with a secret, gitleaks flagged 564, TruffleHog flagged 643, and neither flagged 215. Most misses were passwords typed inside commands, which look like ordinary words to tools that hunt for known key formats.
Why it matters
Permission prompts are meant to keep a coding agent in check. This finding shows that the approval itself can become a plain-text record of your secrets, one that travels with the project folder. Of 16 coding agents whose documentation Apiiro compared, Claude Code is the only one confirmed to save the full approved command in a project file by default.
Last month, WIRED reported that a contractor's Claude Code agent may have exposed Defense Department logins. Accenture denies that account: a spokesperson told WIRED the allegations "were thoroughly and independently investigated and found to be without merit," as covered in that post. For background on how these tools work, see our explainer on what a coding agent is.
In a separate November incident, a University of Chicago law professor said Claude deleted his syllabus and a year of lecture notes while fixing page numbers; we covered what happened and how to protect your files.
Users have flagged the behavior before. A bug report filed August 11, 2025 said approved commands with API keys were stored word for word in settings.local.json. A bot closed it as "not planned" after 60 days without activity, and the four related reports Apiiro cites were all closed the same way without a reply from Anthropic, the researchers say.
Two caveats, both noted by iTWire as summarized by TechWatch: Apiiro sells application security products, and its totals are its own findings rather than an independent replication. The research also shows an exposure risk, not a confirmed breach.
What Anthropic says it may change
Cherny wrote that the team is "looking into what we can do to prevent this." He added that "Everyone should be using auto mode instead," calling it "safer," and that "you should have secret scanning enabled." When another commenter suggested that auto mode could still save these rules when it asks about sensitive commands, Cherny replied: "Yeah good catch. Thinking through what we can do to improve this (ideas welcome)." In another reply he listed "a few possible approaches: making sure auto mode catches this, building in basic secret scanning," and said the team would prototype some of them before it ships something. He gave no release date for a fix.
What to do now
Apiiro's steps, as listed by The Hacker News:
- Search your GitHub organization for
.claude/settings.local.jsonand.claude/settings.json, including git history where the files are gone. - Rotate every password, token and key those files have ever held, before you clean up. Removing the file does not remove it from history or forks. Microsoft separately reported attackers using AI agents to find and abuse secrets leaked on GitHub.
- Stop tracking the local file with
git rm --cached .claude/settings.local.jsonand add it to the repository's own.gitignore. - Open the file on your own computer, even if it was never committed, and delete rules that contain secrets.
- Keep secrets out of commands. Use a variable such as
$DB_URLso the saved rule holds the name, not the value. - Approve patterns such as
Bash(npm run:*)instead of single commands.
Sources
- The Hacker News: Claude Code's "Don't Ask Again" File Exposes Passwords and Keys in 1,122 Public Copies on GitHub
- Claude Code docs: Configure permissions
- Claude Code docs: Settings
- Hacker News: Boris Cherny's reply for the Claude Code team
- TechWatch: Apiiro finds secrets in 1,122 of 104,185 public copies of settings.local.json
