Claude Code’s ‘Don’t Ask Again’ Button Left 1,122 Files of Passwords and Keys Exposed on Public GitHub, Researchers Find

Passwords and secret keys that software developers typed into commands they approved inside Anthropic’s Claude Code are sitting in public GitHub repositories, where anyone on the internet can read them, according to new research from the security company Apiiro. The researchers found 1,122 public copies of a single Claude Code settings file that each hold at least one live-looking secret, and they say the full scale of the exposure is far larger once deleted files, copied repositories and saved chat logs are counted.

Apiiro, whose researchers Shmulik Cohen and Matan Giladi published the findings on 5 November, examined 104,185 public copies of the file — .claude/settings.local.json — spread across 103,617 public GitHub repositories. About 1.1 per cent of those copies contained a secret, and together they held 1,379 distinct credentials. When the researchers widened the search to include earlier versions of the file in git history, a second settings file that teams share deliberately, and saved transcripts of agent conversations, the total rose to 2,539 secrets across 1,994 repositories.

The credentials include 379 database passwords, 122 Supabase service-role keys, 43 SSH logins for public servers, 42 tokens for GitHub, GitLab and npm, and 23 Amazon Web Services keys, according to Apiiro. More than a third of the secrets open a database directly. Among the most serious cases the researchers describe are a database vendor’s own administrator-level cloud key, a production password for an Azure PostgreSQL database, a production token for the payments company Square, and the owner password of a medical-records application’s database. Sixty-three organisations are affected, mostly software companies of various sizes.

Apiiro says it notified the affected organisations on 2 and 3 November, and one of them confirmed that its exposed key was still active. The researchers did not test the credentials they found, so they cannot say whether every secret still works, and they say they have no evidence that anyone has actually used any of them. What they can say is that the secrets are there, in plain text, in public, and that in many cases they have been there for months.

As of the researchers’ snapshot on Monday 2 November, every file containing a secret was still sitting on its repository’s default branch. In half of the affected repositories, the file had been there for at least 217 days. Deleting the file does not fix the problem: older versions remain in the repository’s git history, and the researchers found 734 further secrets across 509 repositories that no longer appear in any current copy of the file, usually because it was deleted. Forks spread the material further still — 211 forks of 74 repositories carry the same secrets as the originals.

How a Single Click Turns a Secret Into a Public File

The leak is not the result of a break-in, a stolen password or a flaw in GitHub. It follows from the way Claude Code remembers a developer’s choices. By default, the tool asks before it runs most shell commands. If the developer answers “Yes, and don’t ask again”, Claude Code saves that decision as an allow rule so that matching commands run without asking in later sessions. The rule is stored in .claude/settings.local.json, a file inside the project folder.

The problem is that the saved rule is the whole command, word for word. When the command the developer approved contains a password or a token typed inline — for example, a database connection string with the password embedded in it, or a login command carrying a credential — the secret is written into the file in plain text alongside the permission. The rule sometimes covers a pattern, such as npm test *, but when it covers one exact command, everything in that command is preserved, including the secret.

Claude Code does try to keep the file out of version control. The first time it writes the file inside a git repository, it adds the file to the developer’s global git excludes, so git on that computer ignores it in every repository. But that protection lives in one person’s git settings on one machine. It does nothing for a file that was already committed before the protection existed, and Claude Code never adds the file to the project’s own .gitignore, so the protection does not travel with the project when somebody else clones it or when the work moves to another computer. Anthropic’s own documentation says that if a developer creates the file manually, they must add it to .gitignore themselves.

The researchers reproduced the behaviour with the current models, Opus 5.5 and Fable 5.1, confirming that it is the tool’s design rather than a quirk of one model. They also compared the documentation of 16 coding agents and found that Claude Code was the only one confirmed to save the full approved command in a project file by default.

Perhaps the most striking detail in the research is that the AI assistant itself often appears to have committed the file. In 539 of the 1,105 repositories the researchers were able to trace, a commit listing Claude as a co-author changed the settings file. The researchers take this to mean that Claude Code frequently commits the file itself as part of its normal work — the agent writing code, approving its own commands, saving the approval, and then publishing the whole package to GitHub.

What the Researchers Found

Apiiro collected its public GitHub data between 1 and 3 November. 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 automated reviewer also had to agree with the classification. The headline numbers are consistent across the independent reports of the research: 104,185 copies of the file examined, 1,122 holding at least one secret, 1,379 distinct secrets in total.

The breakdown shows where the danger concentrates. Database access dominates: 379 database passwords and 122 Supabase service-role keys, which can grant broad control over an application’s data. The remainder includes 43 SSH credentials for public servers, 42 tokens for GitHub, GitLab and npm, and 23 AWS keys. A stolen database password can expose customer records; a stolen cloud key can open storage, computing and billing; a stolen GitHub token can open private repositories and the secrets stored inside them. The researchers say the exposed material belongs to 63 organisations, mostly software companies, and that the strongest cases involve production systems rather than test environments.

The wider count tells a story about how secrets travel once they escape. The shared settings file, .claude/settings.json, which teams commit on purpose, holds secrets in 298 of its 76,011 public copies, mostly inside allow rules. Older versions of the local file, preserved in git history, add 734 more secrets across 509 repositories. Saved agent chat logs add more still. The combined total is 2,539 secrets across 1,994 repositories — and that is only what is visible on GitHub. The researchers note that the same file can also end up inside an npm package, a Docker image, a zip archive or a synced folder, none of which GitHub can see.

Two of the most widely used secret scanners were tested against the exposed files, and both missed a substantial share. Gitleaks flagged 564 of the 1,122 files containing secrets, and TruffleHog flagged 643. Neither tool flagged 215 of them. The reason, the researchers say, is that most misses are passwords typed inside commands. Scanners look for known key formats, and a password after PGPASSWORD=, sshpass -p or mysql -p looks like an ordinary word in an ordinary command line. A clean scan, in other words, is not proof that a repository is clean.

Warnings That Went Unanswered

The behaviour behind the leak is not new, and it had been reported before. On 11 August 2025, a user filed a bug report on Claude Code’s GitHub tracker saying that approved commands containing API keys and tokens were being stored word for word in the settings file. An automated bot closed that report on 3 January 2026 as “not planned”, after 60 days without activity. According to Apiiro, four related reports have all been closed by the same automated bot, the most recent on 6 November, and none of them received a reply from Anthropic.

That silence is part of the story. Anthropic presents itself as the safety-conscious AI laboratory — the company whose co-founder and chief executive, Dario Amodei, has publicly argued for strong oversight of frontier AI systems, and which in February gave $20 million to Public First Action, a political group pushing for AI regulation. The same company’s coding tool has, for more than a year, been saving developers’ passwords into a file that can end up on the public internet, and the people who flagged it say they heard nothing back.

Anthropic has not, as of this writing, issued a public response to the Apiiro findings. The research does not claim that the company was told through a formal security disclosure channel; it says only that the bug reports went unanswered. Whether the company is now preparing a fix, a warning to users, or a change to how approvals are stored remains unknown, and that uncertainty is itself a problem for the thousands of developers who use the tool every day.

What Developers and Companies Should Do Now

Apiiro’s advice begins with a warning: rotate first, clean up second. Anyone who has used Claude Code should search their GitHub organisation for .claude/settings.local.json and .claude/settings.json, and check each repository’s git history for the files even where they have been deleted. Every password, token and key the files have ever held should be changed before any clean-up begins, because deleting the file from the current version of a repository leaves every earlier version intact.

The researchers then recommend stopping the file from being tracked at all, with git rm --cached .claude/settings.local.json, and adding it to the repository’s own .gitignore so the protection travels with the project. Developers should also open the file on their own computers, even if it was never committed, and delete every rule that contains a secret. The durable fix is to keep secrets out of commands entirely: refer to them as variables drawn from a secrets manager, such as $DB_URL, so that the saved rule holds the variable name and not the secret itself, and approve patterns, such as Bash(npm run:*), instead of single commands.

For security teams, the recommendations go further. Agent folders such as .claude/, .cursor/, .gemini/ and .specstory/, and agent memory files, should be treated as holding secrets, in the same way as .env files, on laptops as well as in repositories. Those folders should be added to pre-commit and continuous-integration secret scanning, including scans of git history, and the scanning should be able to catch passwords inside commands, not only known key formats. The local settings file should be added to the organisation’s .gitignore templates, and credentials paired with a public server should be checked first, because those are the ones that give an attacker access.

The researchers also warn that copies of the file that never reach GitHub still matter. The file is plain JSON sitting in a project folder, and it can be swept up into anything the project produces. Malware has already shown an appetite for exactly this kind of material: in September 2025, the Shai-Hulud worm ran the TruffleHog secret scanner over infected computers, and the scanner flagged more than half of the files it examined as containing secrets. A settings file full of live credentials is precisely the prize such malware is built to find.

Analysis: Why It Matters

The Claude Code leak is a small story in one sense: no bank was robbed, no hospital system went down, and nobody has shown that a single exposed credential was ever used. It matters because of what it reveals about how software is now made, who is making it, and how slowly the industry’s safety habits are catching up with its own tools.

Convenience Is the Vulnerability

Every part of this leak was a convenience feature working as designed. The “don’t ask again” button exists so that a developer is not interrupted every time the assistant runs a familiar command. Saving the full command exists so that the permission is precise rather than vague. Storing the file in the project folder exists so that the settings travel with the work. Each choice is reasonable on its own, and together they build a pipeline that carries a live password from a developer’s keyboard into a public repository without anyone noticing.

That is the pattern to watch. The most dangerous security failures in the age of AI agents are unlikely to look like attacks. They will look like features — small acts of helpfulness, each defensible, that add up to an exposure nobody designed. The lesson is not that developers should stop using coding assistants, which are now woven into how much of the world’s software is written. It is that every convenience an agent offers should be examined for what it remembers, where it writes what it remembers, and who can read it afterwards. A permission system that stores secrets in plain text is not a permission system; it is a filing cabinet with the drawer open.

The Agent Is Now the Author

The detail that should most worry engineering leaders is the one about authorship. In nearly half of the repositories the researchers could trace, a commit listing Claude as a co-author changed the settings file — strong evidence that the assistant itself committed the file to GitHub. The human developer is no longer the only actor who can publish a secret. The agent can write the code, approve its own commands, save the approval containing the secret, and then push the whole bundle to a public repository, all in the course of doing exactly what it was asked to do.

This changes the shape of responsibility. Traditional security advice assumes a human being who types a password, sees a warning, and decides whether to commit a file. That model breaks when the person doing the committing is software operating at a speed and scale no human reviews line by line. Organisations that let agents commit code need the same controls they would apply to a junior employee with access to production credentials — except that the agent never sleeps, never asks a second question, and can repeat the same mistake across a thousand repositories before lunch. The fix is partly technical, in the form of scanning and gitignore templates, and partly organisational: somebody senior has to own what the agents are allowed to do, and that ownership cannot be delegated to the agent itself.

The Other Side of AI’s Security Week

The leak landed in the same week as a very different piece of AI security news, and the contrast is instructive. On 5 November, OpenAI announced GPT-6 Cyber, a model built to find software vulnerabilities, prove they can be exploited, and help write the fixes. In testing it found 81 previously unknown high-severity flaws in Firefox and built working privilege-escalation exploits for 948 distinct Linux kernel flaws, as NEXA News HD reported on 6 November. OpenAI classified the model as “Critical” in cybersecurity under its own safety framework, restricted access to vetted defenders, and warned that defenders have only a limited window to use frontier models to secure software before similar capabilities reach attackers.

Put the two stories together and the week reads as a single argument. AI is becoming dramatically better at finding weaknesses in software, and dramatically worse at keeping its own house in order. One company’s model hunts vulnerabilities in Firefox and Linux; another company’s tool quietly publishes its users’ passwords. The same technology that can scan a million lines of code for a flaw can also copy a secret into a file and commit it, because both actions are just pattern-matching at scale. The industry’s safety debate tends to focus on the far future — rogue models, runaway agents, existential risk — while the present keeps producing ordinary, fixable failures that nobody fixes. The Claude Code leak is a present-tense problem with a present-tense solution, and it sat in plain sight for more than a year.

The Accountability Gap

Perhaps the most uncomfortable part of the research is the timeline of warnings. A user reported the behaviour in August 2025. A bot closed the report five months later. Three more reports followed the same path. The most recent was closed on 6 November, the day after Apiiro published its findings. At no point, according to the researchers, did Anthropic reply.

It is worth being fair about what this does and does not prove. Bug trackers for popular open-source projects receive thousands of reports, and automated closure of inactive issues is standard practice. The researchers do not claim they used a formal security disclosure channel, and it is possible the reports never reached the right team. But the pattern is still damning in its own way: a company that sells itself on safety, that funds political campaigns for AI regulation, and whose chief executive lectures the industry on responsibility, appears to have no working channel through which a user can tell it that its tool is leaking passwords — or, if it has one, the message never arrived. Trust in AI companies is built on the belief that they will act on warnings before the damage is done. This episode gives the public reason to doubt that belief, and it gives regulators a concrete example to point to the next time they are told the industry can police itself.

The timing adds pressure. The United States Department of Justice launched a Super Intelligence Task Force on 5 November to police AI misuse by foreign actors, criminals and fraudsters, as NEXA News HD reported on 6 November. Lawmakers in California spent the autumn building the country’s first framework for independent verification of frontier AI systems, and the state’s governor has pushed for a “kill switch” for models that go wrong. The Claude Code leak is not the kind of catastrophe those efforts are aimed at, but it is the kind of ordinary failure that makes the case for outside verification far easier to argue. When a company does not answer its own bug tracker, somebody else will eventually have to ask the questions.

A Blind Spot the Whole Industry Shares

Finally, the research exposes a gap that extends well beyond one company. Two of the best-known secret scanners missed nearly a fifth of the exposed files between them, because they look for known key formats and a password typed inside a command looks like an ordinary word. The scanners were built for a world in which secrets live in configuration files and environment variables. They were not built for a world in which an AI assistant writes the secret into a permission rule, inside a JSON file, inside a folder named after itself.

Every coding agent creates its own folders, its own memory files and its own logs, and every one of them can accumulate credentials in the same way. Apiiro’s advice to treat agent folders as secret-bearing, like .env files, should be adopted far beyond the companies named in its research. The same applies to the habit of typing secrets directly into commands, which long predates AI assistants and has always been bad practice. The agents have simply made an old mistake faster, quieter and harder to notice. The organisations that will fare best are the ones that treat the arrival of coding agents as a reason to rebuild their secret-handling rules from scratch, rather than assuming the old rules still cover the new tools.

What to Watch Next

1. Anthropic’s response: whether the company acknowledges the findings, changes how Claude Code stores approvals, or issues guidance to users — and how quickly any fix reaches the tool.
2. A fix in the tool itself: whether future versions of Claude Code redact secrets from saved commands, add the settings file to project .gitignore automatically, or warn users when an approved command contains a credential.
3. Clean-up across GitHub: whether the 63 affected organisations rotate the exposed credentials, and whether GitHub or the security community scans more broadly for the pattern in other agents’ files.
4. Regulatory attention: whether lawmakers and regulators cite the leak as evidence for independent verification of AI systems, as California’s AI safety framework takes shape.
5. The wider agent ecosystem: whether similar research finds the same flaw in other coding assistants, and whether the industry adopts common rules for how agents store permissions and handle secrets.

Sources

• Apiiro — Coding Agents Leaking Secrets on GitHub: The “Don’t Ask Again” Problem (research, 5 November 2026)
• The Hacker News — Claude Code’s “Don’t Ask Again” File Exposes Passwords and Keys in 1,122 Public Copies on GitHub (7 November 2026)
• Cyber Security News — Claude Code’s “Yes, and Don’t Ask Again” Option Can Leak Passwords and API Keys to GitHub (7 November 2026)
• Cybernoz — Claude Code’s “Don’t Ask Again” File Exposes Passwords and Keys in 1,122 Public Copies on GitHub (7 November 2026)
• MadRobot — Claude Code “Don’t ask again” left secrets in 1,122 GitHub files (7 November 2026)
• BleepingComputer — OpenAI’s new GPT-6 Cyber AI finds 81 Firefox flaws, 948 Linux bugs (6 November 2026)