AW Dev Rethought Flash: Claude Code's "Don’t Ask Again" Is Writing Your Passwords to Disk

Security firm Apiiro found 2,539 secrets across 1,994 public GitHub repositories, leaked through a file most Claude Code users have never opened.

Not through a vulnerability. Through a convenience feature working exactly as designed.

When you approve a shell command with “Yes, and don’t ask again,” Claude Code records an allow rule in the project’s .claude/settings.local.json. The rule contains the command — the full command, verbatim. If that command had a password or a token in it, the credential is now sitting in a JSON file in your working tree, in plain text.

You approved a command once. The password became a config file.

Why the Git Exclusion Doesn’t Save You

Claude Code does try to keep this file out of version control. It adds the path to the user’s global git excludes.

That protects exactly one machine — the one where you clicked the button. It does nothing for a teammate who clones the repo and runs the same flow on their laptop. It isn’t written into the project’s .gitignore, so it isn’t shared with anyone. And it does nothing at all for files that were already committed before the exclusion existed.

The detail that makes this measurable: in 539 of 1,105 traced repositories, the commit that modified the file credited Claude as co-author. The agent was writing credentials into a file and committing it in the same workflow.

Worth noting the rule that avoids this. Exact-command approvals store the literal string. Pattern approvals — allowing npm test * rather than one specific invocation — don’t capture the argument values. Same feature, same button, completely different exposure.

What Is Actually Out There

Apiiro located 104,185 copies of settings.local.json across 103,617 public repositories. Around 1.1% contained at least one secret — 1,122 files holding 1,379 distinct credentials.

The composition is the alarming part. More than a third open a database directly: 379 database passwords. Alongside them, 43 SSH logins, 42 tokens for GitHub, GitLab and npm, and 23 AWS keys. Sixty-three organisations appear among the repository owners.

These aren’t fresh mistakes being caught quickly. Most of the affected files were still sitting on the default branch, and half had been there for at least 217 days. Older file versions in history contribute another 734 secrets across 509 repositories, and every fork carries its own copy.

Apiiro didn’t test whether the credentials still work. One company they notified confirmed its key was live.

Your Secret Scanner Probably Missed It

This is the part that should worry security teams more than the raw numbers.

Gitleaks flagged 564 of the 1,122 files. TruffleHog flagged 643. Neither tool flagged 215 of them.

The misses cluster around one pattern: passwords typed directly into a command line. Scanners are tuned for recognisable credential formats — AWS key prefixes, token shapes, high-entropy strings in assignment syntax. A database password embedded mid-command inside a JSON string matches none of those heuristics well.

So the standard answer — “we run secret scanning, we’d know” — is not reliable here. A fifth of these files were invisible to both major tools.

What To Do Right Now

Search your organisation for .claude/settings.local.json and .claude/settings.json, and search git history, not just the current tree. A file deleted last month is still in the history of every clone.

Rotate every credential those files have ever held, and do it before you clean up. Deleting the file removes the evidence trail, not the exposure — anything that reached a public repository should be treated as compromised regardless of how quickly it came down.

Then fix the mechanism rather than the instance. Untrack the local settings file and add it to the project .gitignore so it’s shared with the whole team. Strip the rules that contain secrets. And change how you approve: prefer command patterns over exact commands, and pull credentials from environment variables or a secrets manager so the literal value never appears in the command you’re approving.

For security teams: treat .claude/ and equivalent agent directories as secret-bearing locations. Add them to your scanning configuration, including history, and specifically for passwords inside command strings. Add the local settings file to your organisation’s .gitignore templates. Prioritise anything paired with a publicly reachable host.

This Is a New Category of Sensitive File

Of 16 coding agents Apiiro compared, Claude Code is the only one confirmed to write the full approved command into a project file by default. So the specific finding is specific.

The general problem is not.

Agent directories now hold configuration that is both executable and, as it turns out, credential-bearing. These folders didn’t exist two years ago. They’re not in anyone’s threat model, not in most .gitignore templates, not in scanner default rules, and not in the mental list of places engineers check before pushing. They accumulate state quietly as a byproduct of using the tool, which is precisely the property that makes them dangerous.

One more thing worth saying plainly: a bug report about this was filed in August 2025 and closed by an automated bot as “not planned.” Apiiro says four related reports met the same fate, with no human response. That gap — between a researcher flagging something and a vendor’s triage automation closing it — is fifteen months long in this case, and the credentials were accumulating throughout.

No official statement from Anthropic appears in the coverage so far.