How Claude Code Leaks Passwords and API Keys into Public GitHub Repositories

Passwords and API keys that developers typed into commands and approved in Claude Code are sitting in public GitHub repositories — anyone can read them. That's the conclusion of US application-security company Apiiro, which on November 5, 2026 published research into a leak mechanism that has already become one of the year's loudest cases in the "AI agents and code security" theme.

The essence of the problem is an ordinary, "convenient" option. When a user chooses "Yes, and don't ask again," Claude Code — Anthropic's coding agent — saves the command verbatim, together with the secret, in the project's settings file. If that file ends up in a public repository, the secret becomes available to the whole world.

Apiiro found 104,185 public copies of the .claude/settings.local.json file in 103,617 GitHub repositories. In 1,122 of them (about 1.1%) lies at least one real secret. The researchers didn't verify whether all are still valid, but one company they notified about the finding confirmed its key was active.

How a secret ends up in the settings file

The mechanism is simple and frightening precisely in its everyday ordinariness. By default, Claude Code asks permission before running most shell commands. A developer asks the agent to check why login to a staging server isn't working, or to run a database migration. The agent composes a command that carries a password or token from configuration — because without it the command simply won't work.

If the user chooses "Yes, and don't ask again," Claude Code saves the approval as an allow-rule in the .claude/settings.local.json file inside the project. From then on, similar commands run without extra prompts. The key nuance: when the rule concerns a specific command (rather than a pattern like npm test *), the entire string is saved to the file — together with the password or token in plain text.

In other words, there's no malicious intent or "model hack" here. This is a standard permission-approval flow: the developer clicks "don't ask again" once, and a secret from the workflow ends up in the project's JSON file. The researchers reproduced this behavior on the latest models — Opus 5.5 and Fable 5.1.

It's important to distinguish this leak from earlier Claude Code configuration vulnerabilities, where attackers changed project settings to steal API keys. Here neither a malicious prompt nor a hacked account is needed: the secret is recorded during ordinary, legitimate work — which is exactly why the problem is so dangerous. The developer does nothing "wrong" except choosing a convenient option.

The scale of the problem: research numbers

Speaking of scale, the 1,122 files with secrets are only the tip. In them Apiiro counted 1,379 unique secrets: 636 keys in known provider formats and 743 passwords or tokens standing next to a public server address. But secrets aren't only in current file versions.

Expanding the search to git history, the shared .claude/settings.json file (which teams commit deliberately), and saved agent logs, researchers reached a total of 2,539 secrets in 1,994 repositories. Old file versions no longer present in the current branch contain another 734 secrets in 509 repositories. Forks compound the problem: 211 forks of 74 repositories carry the same secrets as the originals.

The leak isn't limited to GitHub. Among 31,053 projects on Hugging Face Spaces, Apiiro found 126 file copies, one of them with rules containing a database-service key and a user password. On GitLab.com, out of 69 checked public copies, two held a real secret.

Secrets also hide in agents' auxiliary artifacts. Among 2,523 saved agent chat transcripts, Apiiro found secrets in 120 files in 87 repositories. In 1,200 agent memory files (MEMORY.md and similar), a secret was found in 9 repositories, and among 2,095 task-handoff notes — in 33 files. Tellingly, a third of the notes with secrets were written by the agent itself.

Why the built-in protection doesn't work

Claude Code tries to keep the file away from git. When the agent first creates .claude/settings.local.json in a git repository, it adds it to that user's global git excludes. That means git on that specific computer ignores the file in all repositories.

But this protection, per the researchers, lives only in one user's git settings on one machine. It doesn't work if:

• the file was already committed earlier;
• the folder became a repository after the file appeared;
• the project was cloned to another computer;
• the file was created manually, not through Claude Code.

The main point: Claude Code never adds the file to the project's own .gitignore, so the protection doesn't "travel" with the repository and doesn't extend to other team members. In 539 of 1,105 traced repositories, the file was changed by a commit where Claude is listed as co-author — meaning the agent itself often commits this file.

A separate problem is secret scanners. Gitleaks flagged only 564 of 1,122 files, TruffleHog — 643, and 215 files went unnoticed by either. The reason: a password after PGPASSWORD=, sshpass -p, or mysql -p looks to a scanner like an ordinary word in an ordinary command — without a recognizable key format.

An additional risk is the file itself in plain text on disk. Malware already actively "sweeps" developers' machines hunting for credentials, as shown by recent cases with the compromised LiteLLM package and a malicious Claude Code extension in the Cursor editor. A file with secrets on a laptop becomes yet another ready target for such malware.

What exactly leaked: from DB passwords to medical records

Per Apiiro, 63 organizations were affected — mostly software companies of various sizes. The most serious cases are striking:

• a vendor's own cloud key at administrator level — no expiry, together with the cluster address;
• a B2B startup's production Azure PostgreSQL database password;
• a production Square payment-system token;
• the owner password of a medical-records application's database.

Over a third of the secrets open direct database access: 379 database passwords and 122 Supabase service-role keys. Another 103 Supabase account tokens control all projects in the account. The rest: 43 SSH logins to public servers, 42 GitHub/GitLab/npm tokens, 23 AWS keys, and 6 private keys.

It's important to understand the difference between "leak" and "compromise." A secret in a public repository is a confirmed leak requiring immediate response, but not proof that attackers already used it. Apiiro didn't verify the validity of all keys and doesn't claim anyone used them.

How a developer should protect themselves: a step-by-step plan

The order of actions researchers recommend starts with rotation, not cleanup. Deleting the file doesn't undo the leak — old versions remain in git history and in forks. Therefore:

1. Find .claude/settings.local.json and .claude/settings.json in your organization on GitHub and check each repository's history even where the file no longer exists.
2. First rotate every password, token, and key the file ever contained — and only then clean up.
3. Stop tracking the local file: git rm --cached .claude/settings.local.json and add it to the repository's own .gitignore so the rule travels with the project.
4. Open the file on your computer — even if it was never committed — and delete every rule containing a secret.
5. Don't type secrets into commands directly. Reference them as variables from a secrets manager (e.g., $DB_URL), so the rule stores the variable name, not the secret itself.
6. Approve patterns like Bash(npm run:*), not specific commands.

Separately, remember: the file is an ordinary JSON in the project folder. It can end up not only in git but inside an npm package, Docker image, zip archive, or synced folder.

Recommendations for security teams

For security teams, Apiiro formulates several practical steps:

• Treat agent folders — .claude/, .cursor/, .gemini/, .specstory/ — and agent memory files as secret carriers, on par with .env, both on laptops and in repositories.
• Add them to pre-commit and CI secret scanning, including git history. Make sure the scanner catches passwords inside commands (PGPASSWORD=, sshpass -p, mysql -p, bearer headers), not just known-format keys.
• Add .claude/settings.local.json to your organization's .gitignore templates.
• Prioritize checking credentials next to which a public server stands — those give real access.

Conclusion

The Claude Code case is a reminder that the convenience of AI coding agents can be costly if security isn't built into workflows. The problem here isn't a "malicious" model or a deliberate attack: a routine click of "don't ask again" is enough for a secret in plain text to end up in a public repository.

It's also telling that users reported this behavior back in August 2025 (issue #5544 in the Claude Code repository), but that report was auto-closed with a "not planned" label. Apiiro emphasizes that among 16 compared coding agents, Claude Code is the only one that by default saves the full approved command in the project file.

This case isn't isolated but part of a broader trend. Throughout 2026, researchers repeatedly recorded how AI coding agents unintentionally "carried out" what should have stayed private: from screenshots of internal systems to credentials. The root cause is always the same: the tool stores more than needed, and the developer doesn't see what exactly lands in project files.

The main lesson for Ukrainian teams and developers is simple: if you use AI agents for coding, check your repositories today. Start with rotating secrets — and if you want to learn whether your credentials are already roaming the open web, use the breach check. For those just starting to build a security culture in their team, we recommend starting with the cybersecurity basics.