Claude Code’s “Don’t Ask Again” Button Has Put 2,539 Secrets on Public GitHub

On November 5, 2026, researchers Shmulik Cohen and Matan Giladi at the application security company Apiiro published a scan of public GitHub, and the numbers are uncomfortable for anyone who uses Claude Code. They found 104,185 public copies of a Claude Code file called .claude/settings.local.json. 1,122 of them, about 1.1%, held a real secret. Counting older versions in git history, the shared project settings file and saved agent chat logs, the total came to 2,539 distinct secrets across 1,994 public repositories, owned by 63 organizations. I want to walk through how a single click turns into a stored password, why deleting the file does not fix it, why standard secret scanners missed hundreds of these and what you should check in your own repositories today.

How 1 click turns into a stored password

Claude Code asks for permission before it runs a shell command. One of the options is “Yes, and don’t ask again.” Pick that, and Claude Code saves an allow rule so it can run the same command later without asking. According to Claude Code’s settings documentation, those personal rules live in .claude/settings.local.json inside the project folder.

The rule is the command itself, saved word for word. If the command you approved was a database login with the password typed inline, or a curl request with an authorization header, the password or token goes into the file with it. The Hacker News reported that Apiiro reproduced the behavior with Opus 5.5 and Fable 5.1, and that of 16 coding agents it compared, Claude Code was the only one confirmed to save the full approved command in a project file by default.

Most developers have learned to keep .env files out of git. Very few have ever opened .claude/settings.local.json, and the name suggests it stays local. It only stays local if git is told to ignore it.

Why passwords end up inside commands

Typing a secret into a command is a normal shortcut. A developer debugging a database connects with the password set inline because it is faster than configuring a credentials file. Someone testing an API pastes a bearer token into a curl header. Someone deploying to a server passes an SSH password to a login tool. On a plain terminal, that command lands in shell history on 1 laptop, which is a mild risk.

An agent changes the math. Claude Code proposes the command, the developer approves it, and a single click on “don’t ask again” turns that throwaway line into a saved configuration entry inside the project folder. Lakera’s researchers made the same point after their npm study, noting that developers approve large numbers of shell commands during routine work and that a token in an authorization header can be saved permanently the moment someone picks persistent approval over a one time run.

What the file is supposed to do

Anthropic designed the file to stay private. Claude Code’s documentation describes .claude/settings.local.json as the place for personal settings that are not checked into source control, separate from .claude/settings.json, which teams share and commit on purpose. The documentation says that when Claude Code creates the local file, it configures git to ignore it.

That protection is real, and it has gaps. Apiiro found that on the first write inside a git repository, Claude Code adds the file to the developer’s global git excludes, a setting that lives on that 1 computer for that 1 user. It does nothing for a file that was already committed. It does not travel with the project, because Claude Code never adds the file to the project’s own .gitignore. A teammate on another machine, a CI job, a fresh clone or a developer who created the file by hand gets no protection at all. As iTWire noted, the global exclude is a real protection. It just covers a narrower set of cases than most people assume.

What Apiiro found

Apiiro’s scan covered 104,185 copies of the file in 103,617 public repositories. The 1,122 copies with a real secret held 1,379 distinct values. Older versions of the file that only survive in git history added 734 more secrets across 509 repositories. The shared .claude/settings.json file had secrets in 298 of 76,011 copies, mostly inside allow rules, and saved agent chat logs added more.

Secrets tied to Claude Code settings files, by where Apiiro found them. Source: Apiiro via The Hacker News, Nov 2026

The secrets were the kind that open doors. Apiiro counted 379 database passwords, 43 SSH logins for public servers, 42 tokens for GitHub, GitLab and npm, and 23 AWS keys, according to LavX News. Among the named examples were a database vendor’s own admin level cloud key, a production Azure Postgres password, a Square production token and the owner password of a medical records database, per daily.dev’s summary.

The secret types Apiiro published counts for. Database passwords dominate. Source: Apiiro via The Hacker News and LavX News, Nov 2026

The 63 owning organizations were mostly software companies of all sizes. Apiiro did not test whether the secrets still worked. It notified affected organizations, and 1 company confirmed that its key had been live.

What these secrets give an attacker

The categories matter more than the total. A database password paired with a hostname that answers on the public internet is direct access to the data, with no further hacking needed. An SSH login for a public server is a shell on that server. Apiiro’s advice to security teams is to deal with those pairs first, since a credential plus a reachable host is the shortest path to damage.

Tokens for GitHub, GitLab and npm reach further. They can let someone push code or publish a package version under the owner’s name, which turns 1 leaked token into a risk for everyone downstream who installs that package. The Shai-Hulud worm in September 2025 showed how fast that kind of supply chain abuse spreads once tokens are in the wrong hands. Cloud keys such as the 23 AWS keys Apiiro found can be used to spin up computing resources and run up a bill, or to read whatever storage the key can reach.

Deleting the file does not undo the leak

The obvious fix is to delete the file. It does not work, and Apiiro’s numbers show why. Git keeps every committed version, so the 734 secrets that exist only in older versions are still readable by anyone who browses the history. Forks copy that history too, and Apiiro found 211 forks of 74 repositories carrying the same secrets.

The files also sat in the open for a long time. When Apiiro last checked before publishing, 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, The Hacker News reported. Copies outside GitHub matter as well. The same file can end up inside npm packages, Docker images, zip archives and synced folders.

The only real fix for an exposed secret is to rotate it. Change the password, revoke the token, issue a new key, then clean up the repository.

Why secret scanners missed 215 files

Apiiro ran 2 popular open source scanners, gitleaks and TruffleHog, over every one of the 1,122 files, without live verification. Gitleaks flagged 564 of them. TruffleHog flagged 643. Neither flagged 215.

How many of the 1,122 files with real secrets each scanner flagged. Source: Apiiro via The Hacker News, Nov 2026

The misses follow a pattern. Most involved passwords typed inside commands, such as a value set in a Postgres password variable or passed straight to a MySQL or sshpass login. Scanners are tuned to recognize known key formats, like an AWS key or a GitHub token with a fixed prefix. A plain password sitting in the middle of a command string looks like ordinary text. That is the exact shape of secret the “don’t ask again” rule captures.

Claude often commits the file itself

Apiiro traced the history of 1,105 repositories and found that in 539 of them, a commit listing Claude as a coauthor had changed the settings file. That suggests the agent itself is often the one adding the file to git, as part of a routine commit of everything in the folder.

That lines up with earlier research from GitGuardian. Its State of Secrets Sprawl 2026 report, published in March, found that commits coauthored with Claude Code leaked secrets at about 3.2%, roughly twice the baseline across public GitHub. GitGuardian’s Dwayne McDaniel put the human only baseline at 1.5% in an interview with TFiR.

Leak rates from 3 separate studies. Each counts something different, so treat this as context. Source: Apiiro, GitGuardian, Lakera, 2026

I would be careful reading the GitGuardian figure as proof that the AI writes worse code. Developers still decide what to approve, accept and push. What the data does show is that an agent committing quickly and often will commit whatever is sitting in the folder, including files a human might have paused over.

The bug reports that a bot closed

None of this is new to Anthropic. A bug report filed on GitHub on August 11, 2025, as issue #5544 in the Claude Code repository, said approved commands with API keys and tokens were being stored word for word. According to Apiiro, an automated bot closed it as “not planned” on January 3 after 60 days without activity. 4 related reports were closed by the same bot, the most recent the day before The Hacker News story ran, and Apiiro said none of them received a reply from Anthropic.

Public warnings about secrets in Claude Code settings files since August 2025. Source: Apiiro via The Hacker News, ironPeak, GitGuardian, Lakera

Other users reported the same thing. Another GitHub report, issue #13106, described a developer whose key was flagged as leaked in a public repository, only to find the file holding that key and several other tokens. The reporter asked Claude Code to add the .claude folder to .gitignore automatically.

In February 2026, Niels Hofmans of the security consultancy ironPeak wrote about committing his own settings file by accident, with database passwords and API keys from approved commands still sitting in his git history. He released an open source scanner called claudleak that searches GitHub for AI tool folders such as .claude, .cursor and .continue and runs TruffleHog over them, history included. From a sample of 100 repositories he estimated that about 2.4% of repositories with AI tool folders hold sensitive information somewhere in their history. I could not find a public statement from Anthropic responding to the Apiiro research at the time of writing.

The .claude folder is security sensitive in both directions

The local settings file leaks secrets outward. The shared settings file can be a way in. In January 2026, Anthropic patched CVE-2026–21852, reported by Check Point Research, in which a repository’s .claude/settings.json could redirect Claude Code’s API traffic to another address before the user saw a trust prompt, the fix shipping in version 2.0.65, according to Backslash Security. Backslash recommends treating .claude/settings.json as executable content during code review. Put the 2 findings together and the whole .claude folder deserves the same scrutiny as build scripts and secrets files.

What could change in Claude Code

The people who reported the problem have suggested fixes. The author of issue #13106 asked Claude Code to add the .claude folder, or at least the local settings file, to the project’s .gitignore automatically when it creates it. Apiiro’s write up points to the gap between the global exclude and the project’s own .gitignore as the reason the current protection fails. 1 reader responding to the Lakera research on TechTalks suggested storing approved commands in a separate file that teams could ignore on its own.

I think the most useful change would be the simplest one, which is warning the user, or masking the value, when a command about to be saved as a permanent rule contains something that looks like a password or token. Until something like that ships, the fix sits with developers and security teams.

This keeps happening across AI tools

The settings file is 1 example of a wider pattern. In April 2026, researchers at Lakera, now part of Check Point, monitored about 46,500 npm packages and found 428 that shipped a .claude/settings.local.json file. 33 files across 30 packages contained credentials, roughly 1 in 13, including npm tokens, GitHub personal access tokens and production bearer tokens, as IT Brief reported. Published npm packages are effectively permanent, so every one of those credentials had to be treated as compromised.

Steve Giguere, principal AI security advocate at Check Point, said at the time that AI coding assistants are introducing entirely new ways for secrets to be created, stored and exposed, per SecurityBrief.

Even files without secrets leak useful information. UpGuard analyzed 18,470 Claude Code local settings files from GitHub and found that 21.3% allowed the agent to run curl freely, which an attacker who hijacks the agent through prompt injection could use to download malware or send local data out.

The broader trend is moving the wrong way. GitGuardian counted 28.65 million new hardcoded secrets in public GitHub commits in 2025, up 34% from the year before and the largest annual jump it has recorded. Leaked secrets tied to AI services rose 81%, and it found 24,008 secrets inside MCP configuration files, the files that connect AI agents to outside tools, according to TurboGeek’s summary. Old leaks also linger. The same summary reports that 64% of secrets GitGuardian first detected in 2022 were still active and unrevoked in 2025, which tells you how rarely people rotate a key after it leaks.

New hardcoded secrets found in public GitHub commits each year. Source: GitGuardian State of Secrets Sprawl 2026

What the research leaves out

The research has limits, and they matter. Apiiro did not test whether the 2,539 secrets still work, and it has not said whether anyone has used them. Only 1 key is confirmed to have been live. The 1.1% figure counts public files, so it says nothing about how many Claude Code users have secrets in private repositories or on their laptops. Some secrets will be old test credentials that were rotated long ago.

The risk is still real. Apiiro noted that in September 2025, the Shai-Hulud worm ran TruffleHog over infected developer machines, and that scanner flagged more than half of these settings files as containing secrets. Attackers already have tools that look in developer folders. Now that this research is public, more of them will look in .claude.

The lesson for anyone using an AI coding agent

2 things from this generalize past Claude Code. The first is that agent folders hold secrets, and they deserve the same treatment as .env files. That covers .claude, .cursor, .gemini, .specstory and agent memory files, on laptops as well as in repositories. Add them to the project’s own .gitignore and to your organization’s gitignore templates, so the protection travels with the code to every machine that clones it.

The second is that a convenience click can create a permanent record. If you use Claude Code with any public repository, search your GitHub organization today for .claude/settings.local.json and .claude/settings.json, including git history. Rotate every password, token and key those files have ever held before you clean anything up. Then stop tracking the local file in git, add it to the project’s .gitignore and open the copy on your own machine to delete any rule that contains a secret. Deal first with any credential that sits next to a public hostname, as Apiiro recommends. From then on, keep secrets out of commands entirely by reading them from a secrets manager through environment variables, approve broad command patterns such as running npm scripts so no credential ever lands in a rule, and set up commit hooks and CI secret scanning to read git history and catch passwords inside commands, starting with the 215 shapes that gitleaks and TruffleHog both missed. Claude Code’s own settings documentation shows deny rules that block the agent from reading .env files and a secrets folder, and organizations can push managed settings that individual users cannot override, which is the place to enforce those rules across a team.