Agent security
Claude Code's "don't ask again" file is leaking secrets into public GitHub repos
Apiiro found 1,122 public copies of a Claude Code settings file holding secrets. Approving a command with "don't ask again" can save a credential typed into it, in plain text.
Executive summary
Apiiro found secrets in 1,122 public copies of Claude Code's local settings file, the file that saves a command when a developer picks "don't ask again". A password or token typed into an approved command can end up there in plain text and then get committed. This post covers who is exposed and the checks to run on your repositories this week.
What happened#
Apiiro searched public GitHub for Claude Code's .claude/settings.local.json file and found credentials in it. The Hacker News reported on Nov 7 that Apiiro found 104,185 copies of the file across 103,617 repositories. About 1.1% of them (1,122 copies) hold at least one secret, for a total of 1,379 distinct secrets.
This is the file behind "Yes, and don't ask again." Approving a command that way saves an allow rule for it. If the approved command had a password or token typed into it, that secret can end up in the file in plain text.
The haul includes 379 database passwords, 43 SSH logins, 42 tokens for GitHub, GitLab and npm, and 23 AWS keys. Apiiro didn't test whether the secrets still work, but one company it notified confirmed its key was live. Tech Insider found no on-record statement from Anthropic as of Nov 8.
You may also see a bigger number: 2,539 secrets across 1,994 repositories. Per The Hacker News, that figure also counts shared settings files, old versions and saved agent chat logs. I couldn't open Apiiro's own write-up, so every number here comes from that reporting.
Who is affected#
This hits teams where developers use Claude Code, approve commands with credentials typed inline, and that file ends up in a repository other people can read. The file is meant to stay local. Anthropic's docs say that the first time Claude Code writes it in a repo that doesn't already ignore it, Claude Code adds it to your global git excludes.
That protection has gaps. A global exclude doesn't untrack a file that's already committed, and it lives on one developer's machine, not in the project. In 539 of 1,105 traced repositories, a commit listing Claude as co-author changed the file, so the agent itself may be committing it.
The shared .claude/settings.json is a second exposure: secrets showed up in 298 of 76,011 public copies.
What the reporting doesn't show is any evidence that attackers used these credentials. In private repos the exposure stops at whoever has read access, which is still a lot of people.
What to check this week#
- Search your GitHub organization for
.claude/settings.local.jsonand.claude/settings.json, including git history. - Rotate every credential those files have held before you clean anything up. Deleting the file leaves it in history.
- Stop tracking the local file and add
.claude/settings.local.jsonto your organization's.gitignoretemplates. - Make sure your secret scanning covers git history and passwords typed inside commands, not only well-known key formats.
- Treat agent config folders like
.claude/the way you treat.envfiles. - Tell developers to pull secrets from a secrets manager as variables, so a saved rule holds a variable name and not the value.
- Look at managed settings. Claude Code merges allow rules across scopes unless your organization sets
allowManagedPermissionRulesOnly.
Where Harden helps, and where it doesn't#
Harden Agentic Integrity Foundation (AIF) runs on the developer laptop, outside the agent, at the agent's pre-execution hook. It checks every command, file edit and push against the session's intent before it runs, and it makes those decisions locally in milliseconds. One policy covers every agent, and it starts in watch-only mode.
Here's what that means for this leak. The agent's git add, commit and push get checked before they run, so an agent staging or pushing a .claude settings file is something Harden sees and you can choose to block. The same goes for a file edit that writes a credential into a config file.
There's plenty it won't do. It won't clean up the 1,122 files already public or rotate a credential that has already leaked. It doesn't control what Claude Code itself writes to its settings file when a developer approves a command. It doesn't stop a developer committing by hand outside any agent. And it doesn't replace repo-side secret scanning, scoped credentials or least privilege. It's a layer, not a perimeter.
The checklist above is still the cheapest first step. In watch-only mode, the Records show every command, file edit and push your agents attempt, including any that stage .claude settings files. That tells you what to enforce.
Read more#
For the wider rollout questions, see security review before approving Claude Code.
