Claude Code Leaks Passwords to GitHub: Apiiro Finds Secrets in 1,100 Settings Files

You launch Claude Code, it offers to run a shell command, and to avoid being interrupted you click "Yes, and don't ask again." Convenient. But along with the convenience, you may quietly write your database password into your project. According to researchers at Apiiro, that is exactly what is happening in thousands of repositories.

How a secret ends up in the file

The mechanism is simple. When a user permanently allows a command, Claude Code saves that decision as a rule in the local file .claude/settings.local.json. Sometimes the rule is written as a pattern. But often the command lands in the file as is, along with everything written into it.

Imagine a typical example: you ask the agent to check the database, and it runs psql with a connection string that has the password in plain text. Or it runs curl with an API token in a header. You approve the command "forever," and the entire string with the secret sits in a JSON file.

As long as the file stays on your machine, this is tolerable (unless the machine is hacked). Anthropic's documentation says this file is added to the developer's global .gitignore. But the global .gitignore lives on your computer, not in the repository. If you clone the project to another machine, turn the folder into a repository later, or work in a team, the protection disappears. Apiiro also writes that in many cases Claude Code itself commits changes to this file without any user involvement.

The scale, and why scanners don't save you

Apiiro analysts found more than 100,000 cases in which a local Claude Code settings file ended up in a public GitHub repository. Most of them are harmless. But in roughly 1,100 files from 63 organizations, they found real secrets: API tokens, database passwords, private keys, and even root logins.

Deleting the file from the repository is not enough. If the project has already been forked, the secrets remain in the forks. That means a key must be considered compromised as soon as it has appeared in a public commit even once.

It is also unpleasant that the usual secret scanners do not guarantee protection. Of the ~1,100 secrets found, 215 were noticed by neither gitleaks nor TruffleHog. The reason is clear: the secret is embedded in a command string rather than sitting in the familiar KEY=value format.

The history doesn't inspire confidence either. The problem was raised in bug reports as early as August 2025. Other reports mentioned that the file sometimes failed to get into .gitignore, and that sensitive commands could be written to a different file that was not protected at all. All of these reports were closed without action after 60 days of inactivity.

Over the weekend, in a Hacker News thread, Boris Cherny of the Claude Code team replied that the team is "looking into what can be done." According to him, such files should almost never end up in git, and problem cases arise when the files were created and committed manually. He recommended auto mode, where classifiers decide for themselves which permission requests are routine. When another user pointed out that sensitive commands can be saved to settings in auto mode too, Cherny acknowledged: "good catch." The team views a built-in secret scanner in Claude Code as a possibility for the future.

What to do today

Don't wait for a patch. Here is a short checklist for developers and team leads:

• Add .claude/settings.local.json to the .gitignore of the repository itself, not just the global one.
• Check the history: git log --all -- .claude/settings.local.json. If the file was ever committed, open it and look for passwords and tokens.
• Reissue everything you find. Deleting the file does not revoke the key, especially if forks exist.
• Don't put secrets into commands you approve "forever." Use environment variables or a secrets manager.
• Enable a pre-commit secret scanner, and don't treat it as a cure-all: the 215 misses show that one tool is not enough.
• Review the settings file itself before pushing. It's plain JSON, and it's easy to spot anything extra.

This is not the first time an AI agent has accidentally exposed data. Last month Meta suspended the sharing feature in its Muse agent: researchers found that links to shared materials were easy to guess.

The lesson applies to any agentic tool. Everything an agent remembers for your convenience becomes one more file that someone might accidentally publish. Treat agent configs as strictly as you treat .env.