A convenience click in Claude Code can turn a one-off approved command into a plaintext secret store. Security firm Apiiro reported on November 5, 2026, that choosing “Yes, and don’t ask again” saves the approved shell command — word for word, password included — in a project file named .claude/settings.local.json. Researchers say they found 1,122 public copies of that file on GitHub holding at least one secret. The Hacker News and iTWire published independent recaps of the write-up on November 7. As of November 8, i10x found no public statement from Anthropic confirming a product fix.
Quick Take
- The mechanism: Claude Code can save an exact approved Bash command as an allow rule in .claude/settings.local.json. If that command contained a password, token or key, the secret is stored in plaintext.
- The count: Apiiro reported 104,185 public copies of the file in 103,617 repositories, and 1,122 copies (about 1.1%) holding at least one secret — 1,379 distinct values in current copies.
- The wider exposure: Counting git history, shared .claude/settings.json files and saved agent chat logs, Apiiro put the total at 2,539 secrets across 1,994 repositories. One notified company confirmed its key had been live.
- The catch: Claude Code adds a machine-local git exclude, not a project .gitignore. Removing the file does not clean history or forks. i10x found no public Anthropic fix statement as of November 8, 2026.
What happened
Apiiro researchers Shmulik Cohen and Matan Giladi published the findings on November 5. They searched public GitHub between November 1 and 3, according to iTWire, and notified affected organizations on November 2 and 3. The Hacker News reported that one company confirmed its exposed key had still been live.
By default, Claude Code asks before it runs most shell commands. If the user picks “Yes, and don’t ask again,” the tool writes an allow rule to .claude/settings.local.json inside the project, matching Anthropic’s permissions documentation. Sometimes that rule is a pattern, such as npm test *. Sometimes it is one exact command. When it is the exact command, any password or token typed into it is saved too.
The researchers reproduced the behavior with Anthropic’s latest models, Opus 5.5 and Fable 5.1, The Hacker News reported. In 539 of the 1,105 repositories they traced, a commit listing Claude as a co-author changed the file — which they take to mean Claude often commits the file itself. That is an inference from commit metadata, not proof that Claude introduced every secret.
Background: a local file that does not stay local
Claude Code tries to keep the file out of git. The first time it writes settings.local.json in a git repository, it adds the path to the user’s global git excludes, Anthropic’s settings documentation says. Git on that computer then ignores the file in every repository. The protection stays on one user’s machine. It does nothing for a file that was already committed, and Claude Code never adds the path to the project’s own .gitignore, so the protection does not travel with the repo, a fresh clone, another laptop, or a folder that becomes a repository later.
Users had already flagged the behavior. The Hacker News cites an August 11, 2025 bug report that said approved commands with API keys and tokens were being stored word for word; an automated bot closed that report as “not planned” on January 3 after 60 days without activity. A later report, GitHub issue #13106, filed on December 4, 2025, described API keys landing in settings.local.json and then in a public repository because .claude/ was not gitignored. An automated bot closed it as a duplicate. The Hacker News said the four related reports the researchers cited had all been closed by the same bot, the most recent on November 6, and that none received a reply from Anthropic.
iTWire notes that security firm ironPeak described a similar committed settings file in February 2026. Those earlier reports support the mechanism; they do not independently verify Apiiro’s new repository totals. Apiiro sells application and agent security products, which iTWire also flags as context for reading a vendor study.
| Finding | What Apiiro reported | Caveat |
|---|---|---|
| Public copies of .claude/settings.local.json | 104,185 copies in 103,617 repositories | Public GitHub search; collected 1–3 November 2026, per iTWire |
| Copies holding at least one secret | 1,122 copies, about 1.1% | Apiiro did not test whether the secrets still work |
| Distinct secrets in current copies | 1,379 | Classified by known key formats, password-plus-public-server context, and an AI reviewer |
| Broader scan (history, shared settings, chat logs) | 2,539 secrets across 1,994 repositories | Includes 734 secrets only in history across 509 repos, plus shared settings.json and transcripts |
| Database passwords / SSH / git-host tokens / AWS keys | 379 database passwords; 43 SSH logins; 42 GitHub, GitLab and npm tokens; 23 AWS keys | Exposure finding, not a confirmed breach of those systems |
| How long they sat in public | Every secret-bearing file was still on the default branch as of the Monday before publication; median presence about 217 days | Deleting the current file does not remove git history or forks |
| Forks and Claude-coauthored commits | 211 forks of 74 repositories; Claude listed as co-author on changes in 539 of 1,105 traced repos | Co-authorship does not prove Claude pushed every secret |
| Scanner blind spots | Of 1,122 secret-bearing files, gitleaks flagged 564 and TruffleHog 643; neither flagged 215 | Most misses were passwords typed inside ordinary commands |
How the leak works
The failure is not a hostile prompt tricking the model into stealing a password. It happens in an ordinary, authorized workflow: a developer types a secret into a command, approves it so Claude Code will stop asking, and the approval record becomes another copy of the secret.
Among current secret-bearing files, more than a third opened a database directly, including 379 database passwords, The Hacker News reported. Other finds included 43 SSH logins for public servers, 42 tokens for GitHub, GitLab and npm, and 23 AWS keys. Among owners, Apiiro counted 63 organizations, mostly software companies of all sizes. The strongest cases, the researchers said, included a database vendor’s own admin-level cloud key and the owner password of a medical-records database.
As of the Monday before The Hacker News recap, every file with a secret was still on its repository’s default branch, and in half of those repositories it had been there for at least 217 days. Older versions of the file contained 734 more secrets across 509 repositories that no longer appear in any current copy, usually because the file was later deleted. Forks spread the files further: 211 forks of 74 repositories carried the same secrets as the originals.
Secrets also sat in 298 of 76,011 public copies of the shared .claude/settings.json file, which teams often commit on purpose, mostly inside allow rules. Including those, the older versions, and saved agent chat logs, Apiiro’s extended total was 2,539 secrets across 1,994 repositories.
Of 16 coding agents whose documentation the researchers compared, Claude Code was the only one confirmed to save the full approved command in a project file by default, Apiiro said.
Common secret scanners miss many of these files because they look for known key formats. A password after PGPASSWORD=, sshpass -p, or mysql -p can look like an ordinary word in an ordinary command line. Copies that never reach GitHub still matter: the file is plain JSON in the project folder, and it can also travel inside an npm package, a Docker image, a zip archive or a synced folder.
What teams should do
Apiiro’s advice, as summarized by The Hacker News, starts with rotation, not cleanup. Search the organization for .claude/settings.local.json and .claude/settings.json, including git history even where the files are gone. Rotate every password, token and key those files have ever held, then stop tracking the local file with git rm –cached .claude/settings.local.json and add it to the repository’s own .gitignore. Open the file on each developer’s machine, even if it was never committed, and delete every rule that contains a secret.
The researchers also recommend keeping secrets out of commands — referring to them as variables from a secrets manager, such as $DB_URL, so the saved rule holds the variable name — and approving patterns such as Bash(npm run:*) instead of single commands. Security teams should treat agent folders such as .claude/, .cursor/, .gemini/ and .specstory/ as secret-bearing, like .env files, and make scanners catch passwords inside commands rather than only known key formats.
The trending claim that “Anthropic has updated newer versions” could not be verified from public sources as of November 8, 2026. i10x found no changelog note or company statement confirming a fix for this specific save-the-full-command behavior.
Pros and cons
For users
- Pro: Standing approvals save time on repeated, boring commands, which is why the “don’t ask again” option exists.
- Con: A single approval can write a live password into a project path that looks “local” but is easy to commit, copy or scan.
For developers
- Pro: The fix path is concrete: rotate anything the file ever held, untrack it, add a project .gitignore rule, and approve patterns instead of exact secret-bearing commands.
- Con: Machine-local git excludes do not travel with the repo, and deleting today’s file leaves history, forks and packaged copies untouched.
For companies
- Pro: Apiiro’s public counts give security teams a searchable filename and a clear playbook, including checks of agent folders in CI and pre-commit hooks.
- Con: Exposed database passwords, cloud keys and admin credentials create an incident-response job even when no confirmed abuse has been shown, and vendor tooling that writes secrets by default shifts the burden onto every customer.
What X is saying
Security accounts treated the finding as a “rotate first” problem, not a curiosity.
‼️ Claude Code’s “Don’t Ask Again” option can save passwords and API keys in plaintext. Apiiro found 2,539 exposed secrets across 1,994 public GitHub repos, including database credentials, SSH logins, and cloud keys. Deleting files doesn’t erase Git history.
— The Hacker News (@TheHackersNews) November 7, 2026 · View on X
“don’t ask again” shouldn’t mean “save my password”. claude code can save full commands, including secrets, in its local settings file. apiiro found secrets in 1,122 public copies of that file. if yours leaked: rotate the secrets first. deleting the file isn’t enough.
— Lenny Enderle (@lenny_enderle) November 7, 2026 · View on X
PSA for teams using AI coding agents: clicking “don’t ask again” in Claude Code can save the exact command, secrets included, in .claude/settings.local.json. Apiiro found 1,122 public GitHub copies holding secrets. Gitignore it and rotate anything it ever held. #DevSecOps
— Josh Watson (@ilikejoshwatson) November 7, 2026 · View on X
Developer Cagatay put the same warning more bluntly: “if you ever clicked ‘yes, and dont ask again’ in claude code, open .claude/settings.local.json.”
Critical analysis
The important distinction is between exposure and confirmed compromise. Apiiro did not try the credentials, as both The Hacker News and iTWire emphasize. A value counted as a secret when it matched a known key format or when a password or token sat beside the address of a public server, and an AI reviewer also had to agree. That is a serious exposure finding. It is not, on its own, evidence that attackers used these secrets or that every classified value still works.
Even so, the design choice is hard to defend. Saving the exact approved command is convenient, and it is documented. Combining that with a protection that lives only in one user’s global git excludes — while never writing the path into the project’s .gitignore — makes accidental publication the default failure mode. The scanner misses sharpen the problem: passwords inside ordinary command lines are exactly the secrets teams are most likely to type once and forget.
The long median presence, about 217 days, also matters. A secret that has been on a default branch for months is not a same-day oops. Forks, packaged artifacts and chat logs extend the blast radius beyond the file sitting in HEAD today.
What’s still open
- Will Anthropic change Claude Code so standing approvals store patterns rather than exact secret-bearing commands, or move this file out of the project tree?
- Will Anthropic add .claude/settings.local.json to the project’s .gitignore by default, or reply to the closed GitHub reports?
- How many of the 1,379 current secrets, or the 2,539 in the extended set, are still valid?
- Have any of the exposed database, cloud or medical-records credentials been abused?
About the analysis
Researched and written with AI assistance under the editorial responsibility of the i10X News team. The title image is an AI-generated illustration. Read our AI Use Policy. Spotted an error? Request a correction.
This independent, research-based i10x analysis draws on Apiiro’s November 5 research write-up (the page is script-rendered; figures were verified against recaps by The Hacker News and iTWire, which quote researchers Shmulik Cohen and Matan Giladi), Anthropic’s Claude Code settings behavior as described in those reports and in GitHub issue #13106, and public posts on X. Apiiro did not test the credentials, so the findings describe exposure, not demonstrated intrusion. i10x found no public Anthropic statement confirming a fix as of November 8, 2026. More on Anthropic and Claude.
i10x Perspective
Agent tools now write durable permission files inside project folders, so a routine “yes” is also a credential-storage decision. The lesson is older than Claude Code: anything an assistant saves next to the code will eventually be committed, forked or scanned. Until coding agents treat standing approvals like secrets managers treat vault paths — patterns and variable names, never the secret itself, and a .gitignore rule that travels with the repo — every team using them needs to search history for .claude/settings.local.json and rotate first.
