Your agent's "don't ask again" list may hold your passwords

Every developer who uses a coding agent has clicked it: “Yes, and don't ask again.” It saves a prompt, and after the tenth one it feels like the only sane answer. Research from the security company Apiiro, covered on 7 November by The Hacker News and iTWire, shows where those approvals end up, and what sometimes comes with them.

What the researchers found

When you approve a shell command for good in Claude Code, it saves that command as an allow rule in .claude/settings.local.json inside your project. It saves the command exactly as it was run. If the command had a password or token typed into it, that is now sitting in a JSON file in plain text.

That file is meant to stay on your machine. Claude Code's documentation says that the first time it writes the file in a git repository, it adds it to your global git excludes, so it stays out of your commits. The catch is that the protection lives in your personal git config, not in the project. If the file was created by hand, committed before, or the project is cloned somewhere that rule doesn't exist, nothing stops it from being pushed.

And it is being pushed. According to the reports:

Apiiro found 104,185 public copies of the file on GitHub, across 103,617 repositories;
1,122 of them, about 1.1%, contained at least one secret, for 1,379 distinct secrets;
those included 379 database passwords, 43 SSH logins for public servers, 42 GitHub, GitLab and npm tokens, and 23 AWS keys;
counting older versions of the file, the shared .claude/settings.json and saved agent chat logs, the total was 2,539 secrets across 1,994 repositories;
in 539 of 1,105 traced repositories, a commit co-authored by Claude changed the file.

Apiiro did not test whether the secrets still work, though The Hacker News reports that one company it notified confirmed its key was live. There is no report of anyone using them.

Why secret scanners missed many of them

This is the part worth passing on to your security team. Most scanners look for known key formats, like an AWS key or a GitHub token. A password typed inside a command, after PGPASSWORD=, sshpass -p or mysql -p, just looks like text. The Hacker News reports that Gitleaks flagged 564 of the 1,122 files and TruffleHog flagged 643, and 215 were caught by neither.

The response

The Hacker News and iTWire report that a bug report describing this behavior was filed in August 2025 and closed automatically for inactivity in January, which is not the same as a fix. Cybernews reports that Boris Cherny, who leads Claude Code at Anthropic, replied on Hacker News that “this is not a file you should check into source control,” that Claude Code gitignores it when it creates it, and that developers should turn on GitHub secret scanning whichever agent they use.

Both things can be true. The tool tries to keep the file out of git, and in practice the file still ends up in public repositories. The issue is not limited to Claude Code either: Cybernews notes that agents also write secrets into chat transcripts, memory files and other tools' auto-approve settings.

Check your repositories

Look for the files and their history. In each repository:
```
git ls-files | grep -E '\.claude/settings(\.local)?\.json$'
git log --all --oneline -- .claude/settings.local.json
```
If the first command lists settings.local.json, or the second shows commits, it has been in your history. Repeat for other agents' folders, such as .cursor/ and .gemini/.
Read what is in it. Open the file and look at every saved command for passwords, tokens or connection strings. Check the shared .claude/settings.json too.
Rotate first, clean up second. Deleting the file does not remove it from old commits, forks or clones. Any credential that was ever in it should be treated as exposed and replaced.
Stop tracking it and ignore it in the project.
```
git rm --cached .claude/settings.local.json
echo '.claude/settings.local.json' >> .gitignore
```
A line in the repository's own .gitignore protects everyone who clones it, not only you.

What to change on your team

Never type secrets into commands. Reference them from a secrets manager or an environment variable set outside the command, so a saved rule only ever contains a name. iTWire points out that an inline assignment such as PGPASSWORD=... still puts the password in the command text.
Approve patterns, not exact commands. A narrow rule like npm run test * is safer and more useful than a saved one-off command with a password in it.
Treat agent folders like .env files. Add .claude/settings.local.json to your organization's .gitignore templates, and decide which agent files are shared on purpose.
Scan for passwords in commands. Turn on secret scanning in your Git host and in pre-commit, and tune it to catch patterns like -p and PASSWORD= in agent config files.

The takeaway

“Don't ask again” is a convenience, and it stores more than people expect. Agents now write files into your repository that nobody on the team chose to write, and some of them hold whatever you typed. Spend ten minutes checking your repositories, rotate anything you find, and make the project's own .gitignore the place that keeps personal agent files out of git.

Sources: Apiiro, The Hacker News (7 November 2026), iTWire (7 November 2026), Cybernews, Claude Code settings documentation.