A Permission Feature Just Sent Your Passwords to GitHub

When Claude Code asks permission to run a Bash command, it offers three choices. “Yes” and “No” do what you’d expect. But “Yes, and don’t ask again” does something most developers don’t realise: it saves the entire approved command — verbatim — as an allow rule inside .claude/settings.local.json at the root of your repository.

If that command was PGPASSWORD="mypassword" psql -h db.example.com -U admin production, then your database password just landed in a local file. And if that file made it into a git commit — which is surprisingly easy to do — it’s now on GitHub.

Apiiro security researchers Shmulik Cohen and Matan Giladi published their findings on 5 November 2026. They scanned 104,185 public copies of .claude/settings.local.json across 103,617 GitHub repositories. In 1,122 of those files they found live credentials. After pulling older commits, forks, and the shared .claude/settings.json file into the count, the total reached 2,539 distinct secrets spread across 1,994 repositories and 63 organizations — “mostly software companies,” according to CybersecurityNews.

What Was Exposed, and How Bad Is It

The breakdown by credential type, as reported by CybersecurityNews and a detailed analysis on DEV Community citing Apiiro’s data, shows that production-critical credentials make up the bulk of the leaks:

The numbers above cover the initial snapshot (1–3 November 2026) plus older commits and forks that Apiiro pulled separately, as reported by Runtimewire. 734 of the total secrets came from earlier commits still in git history, spread across 509 repos. 211 forks of 74 repos carry copies of those secrets — meaning the cleanup problem is wider than just the original repo.

Why Claude Code Is Different From Other Agents

Claude Code’s permission model is designed to reduce friction: approve a command once and never approve it again. But the place it saves that approval matters. Claude Code writes to .claude/settings.local.json in the repo root, not to a machine-level config outside the working tree.

When Claude Code first writes the file, it adds the path to the developer’s global git excludes file on that machine. That protects the file on the machine where it was first written. It does not add a line to the repo’s own .gitignore, so the protection does not travel when the repo is cloned elsewhere, and it offers no protection against files that were committed before Claude Code was first run on that repo.

According to the DEV Community analysis, Apiiro compared 16 coding agents’ permission systems. Claude Code was the only one that saves the full approved command text — including any inline secrets — to a project file by default. The others either store approvals outside the repo, store a sanitised pattern rather than the literal command, or don’t offer a persistent “don’t ask again” mode that writes to a project file.

The involvement of the agent itself made the problem worse. In 539 of 1,105 repos Apiiro could trace, a commit whose author line listed Claude as a co-author was what added or changed .claude/settings.local.json. That is roughly half of all traced cases: the agent ran a command, got approval, wrote the approval file, and then committed it without the developer noticing.

A GitHub issue (anthropics/claude-code #5544) filed in August 2025 had already reported that “commands with credentials are stored as is with plain text credentials.” Anthropic’s bot closed the issue as “not planned” on 3 January 2026 after 60 days of inactivity, according to the DEV Community analysis. As of 7 November 2026, none of the sources found a public response from Anthropic to Apiiro’s findings.

Scanner Blind Spots: 215 Files Went Undetected

The credential exposure is compounded by a gap in the main open-source secret scanners. Apiiro ran both Gitleaks and TruffleHog across the 1,122 exposed files, with these results:

The 215 files that evaded both scanners mostly contained passwords without a provider-specific format — the kind you pass directly to a CLI tool: PGPASSWORD=…, sshpass -p …, mysql … -p…. These patterns are legitimate in shell scripts and don’t match the structured regexes that Gitleaks and TruffleHog use to detect provider-specific keys. If you’re relying only on secret scanners in CI and treating a clean pass as confirmation of safety, you’re not catching these.

For Swiss & EU teams

If any of your Claude Code-generated commits contained credentials that give access to systems processing personal data, you are likely looking at a reportable data breach. Under GDPR, an unauthorised third party gaining access to credentials is a personal data breach once someone has used or could use those credentials to access data about individuals — the 72-hour notification clock to your supervisory authority starts from when you become aware. Under Switzerland’s FADP, a data security breach must be reported to the Federal Data Protection and Information Commissioner (FDPIC) as quickly as possible if it is likely to result in a high risk to data subjects; exposed database credentials that contain personal data fall in that category.

NIS2-regulated entities face a tighter regime: a 24-hour early-warning followed by a 72-hour incident report, then a final report within one month. Neither GDPR, FADP, nor NIS2 grants an exception because an AI agent was the one that committed the file.

What to Do on Monday

1. Rotate credentials before cleaning up history. Deleting the file or rewriting git history does not invalidate an already-exposed credential. Rotate first. For AWS keys, disable in IAM immediately. For database passwords, change them before anything else.

2. Find and untrack the file in every repo. Run git ls-files .claude/settings.local.json to check if the file is tracked. If it is:

git rm --cached .claude/settings.local.json
echo ".claude/settings.local.json" >> .gitignore
git commit -m "Remove Claude Code approval file from tracking"

3. Scan git history — not just the working tree. The present-state file is only part of the problem. Run:

git log --all -p -- .claude/ | grep -nE 'PGPASSWORD=|sshpass -p|mysql .*-p'
gitleaks git -v
trufflehog git file://.

Also check .claude/settings.json (the shared variant) and any agent session transcript files.

4. Fix the root cause: use variable names, not literals. Export secrets to your shell first, then pass the variable: PGPASSWORD="$DB_PASSWORD" psql …. When you approve this, the rule saves $DB_PASSWORD, not the value. For anything production, use a secrets manager and pass the reference.

5. Add AI agent config dirs to org-wide scanning. Your CI secret scanner should cover .claude/, .cursor/, .gemini/, and .specstory/ in both pre-commit hooks and pipeline jobs — and must include git history, not just the working tree. Teams already following the guidance in How to Secure Your AI Coding Agent Pipeline (2026) should add agent permission files explicitly to their scope. See also Claude’s Unintended Actions: Anthropic’s Report and Your Fix for the broader context of agent-committed changes your team may not be reviewing. And if you use git-based CI and want a fuller picture of agent config attack surfaces, the GitSpawn analysis covers what malicious configs can do once an agent reads them.

Further Reading

• Claude Code’s “Yes, and Don’t Ask Again” Option Can Leak Passwords and API Keys to GitHub — CybersecurityNews (7 November 2026): the original coverage with all secret type counts and the confirmed-live-key detail
• Claude Code’s ‘Don’t Ask Again’ Saved Secrets in 1,122 Public Files. 215 Beat Both Scanners — DEV Community: the most detailed breakdown, including the 16-agent comparison and the git-history numbers
• Apiiro finds secrets in 1,122 public Claude Code settings files — Runtimewire: short factual summary of Apiiro’s methodology and total count

Your turn: Has your team already added .claude/settings.local.json to your .gitignore template, or are you finding out about this now? Reply to our newsletter or send us a note — we’ll feature the best mitigation setups in the Friday Scorecard.

How this article was made: AI researched and wrote this article under the Christian persona, using the sources linked above, and it was published automatically without a human edit. Editorial guidelines are set by Adi. Spotted an error? Tell us and we will correct it.