Every AI coding agent asks permission before it runs a shell command. And every developer, sooner or later, gets tired of being asked. Claude Code offers a way out: “Yes, and don’t ask again.” Click it, and the tool saves the approved command so it won’t prompt for it next time.
The problem is what it saves. It stores the exact command string, in a file called .claude/settings.local.json inside the project folder. If the command was psql with a password, or curl with a bearer token, or sshpass with a root password, the secret is now part of a permission rule in a project file. And project files get committed.
We wanted to know how often that happens, so we downloaded every public copy of the file on GitHub: 104,185 of them, in 103,617 repositories. 1,122 hold a real secret. Adding git history, the shared settings file teams commit on purpose, and agent chat transcripts, we found 2,539 distinct secrets in 1,994 repositories, across 63 organizations. They include 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. One company confirmed its key had been live.
Nobody meant to publish a key
The file is supposed to stay local. Claude Code adds it to the developer’s global git ignore list when it creates it, which covers the common case. It doesn’t cover a folder that becomes a repository later, a clone on a second machine, or a file someone already committed. The rule never goes into the project’s own .gitignore, so the protection doesn’t travel with the code.
Often the agent commits the file itself. In 539 of the 1,105 repositories we traced, a commit co-authored by Claude changed it. The developer approved a command, the agent recorded it, and the agent shipped the record.
Once public, these files stay public. In the median affected repository the file had been on GitHub for 217 days; in 118 repositories, more than a year. Deleting it is not enough: earlier versions in git history held another 734 secrets that appear in no current copy, and 211 forks carry the same secrets.
Your scanner probably misses a fifth of them
We ran gitleaks and TruffleHog, two of the most widely used open-source secret scanners, over all 104,185 files. Of the 1,122 with a real secret, 215, about one in five, were flagged by neither.
The reason is structural. Secret scanners are tuned to key formats: a provider prefix followed by a long random string. A password typed after PGPASSWORD=, sshpass -p or mysql -p is just a word in a command line. Agents create exactly this kind of record: they log what was run, not what was a credential. The same pattern shows up in agent chat transcripts, memory files and handoff notes, and a format-based scanner misses it in all of them.
GitHub is just where we could count
Most of these files never reach GitHub. They sit in plain text on developer laptops, in every project where someone clicked “don’t ask again”. That matters because attackers already harvest developer machines in bulk. The Shai-Hulud npm worm ran TruffleHog over its victims’ files; TruffleHog flags 643 of the 1,122 files we found. Weeks earlier, malicious Nx packages told the victim’s own AI coding agents to search the disk for secrets.
The file can also leave without git: inside a published npm package, a Docker image built with a broad copy command, a zip archive, or a synced folder.
What to do
For developers:
1. If the file is tracked in a repository, untrack it with git rm –cached .claude/settings.local.json and add it to the repository’s own .gitignore.
2. Rotate every credential the file has ever held. Removing the file doesn’t clear git history, forks or clones.
3. Open the file even if it was never committed, and delete every rule that contains a secret.
4. Stop typing secrets into commands. Reference them as environment variables, so the rule records $DB_URL rather than the password.
5. Approve patterns, such as npm run:*, instead of literal commands.
For security teams:
1. Treat agent folders (.claude/, .cursor/, .gemini/, .specstory/, agent memory files) as secret-bearing, like .env files, on laptops as well as in repositories.
2. Scan them in pre-commit and CI, including history, and make sure the scanner catches passwords inside commands, not only provider key formats.
3. Add .claude/settings.local.json to your organization’s .gitignore templates.
4. Triage credentials paired with public hosts first. Those are the ones that give access.
The bigger lesson
This isn’t a bug in one model. It is a product behavior, and it reproduces with Anthropic’s latest models. Coding agents are built to remember what they did so they can do it again with less friction. Each piece of that memory is a file, and files end up in repositories, packages and backups. As agents take on more of the work, the records they keep become a new place for secrets to leak, and they need the same scrutiny we already give to .env files and CI logs.
______
About the author
Shmulik Cohen is an AI Security Researcher at Apiiro, where he researches how AI coding agents and the software supply chain expose organizations to risk, from leaked credentials to malicious packages.
Join our LinkedIn group Information Security Community!
——————————————————-
Click Here For The Original Source.
