Claude Code Settings Leak 2026: How “Don’t Ask Again” Approvals Put 2,539 Secrets in Public Repos

On 5 November 2026, the application security firm Apiiro published research showing that Anthropic's Claude Code coding agent can write secrets into project files that developers then push to public repositories. When a developer approves a shell command with "Yes, and don't ask again", Claude Code can save the approved command word for word as an allow rule in .claude/settings.local.json, including any password or token typed into it. Apiiro found 104,185 public copies of that file, 1,122 of them holding at least one secret. Counting shared settings files, git history and saved chat logs, it found 2,539 secrets across 1,994 repositories, including database passwords, SSH logins, GitHub, GitLab and npm tokens and AWS keys. The Hacker News reports that the researchers did not test whether the secrets still work, although one notified company confirmed its key had been live. No abuse of the exposed secrets has been reported. This is exposure research, not a confirmed breach.

At a glance

What happened

Claude Code, like other AI coding agents, asks a developer before it runs a shell command. One of the answers is "Yes, and don't ask again", which turns the approval into a standing permission. According to The Hacker News, Claude Code can save that approved command word for word as an allow rule in .claude/settings.local.json inside the project, in plain text. If the command contained a password or token, the secret now lives in a file in the repository folder. The Hacker News reports that Claude Code adds the file to the user's global git excludes but not to the project's .gitignore, which does not help where the file has already been committed or copied outside git. In 539 of 1,105 repositories Apiiro traced, a commit listing Claude as co-author changed the file. The researchers say they reproduced the behaviour with current models.

Apiiro collected data between 1 and 3 November 2026, according to iTWire. It examined 104,185 public copies of the local settings file across 103,617 repositories and classified 1,122 copies, about 1.1%, as holding at least one secret, with 1,379 distinct values. The Hacker News reports that more than a third of these open databases directly, including 379 database passwords, alongside 43 SSH logins, 42 tokens for GitHub, GitLab and npm, and 23 AWS keys. Among the 63 organisations that own affected files, the most serious cases reportedly include a database vendor's admin-level cloud key and the owner password of a medical-records database. Older versions of the file held 734 more secrets across 509 repositories, and 211 forks of 74 repositories carried the same secrets. Including shared .claude/settings.json files (298 copies with secrets), history and saved chat logs, the total came to 2,539 secrets across 1,994 repositories.

The exposure had often been there for a long time. According to The Hacker News, every file with a secret was still on its repository's default branch when the research was done, and in half of those repositories it had been there for at least 217 days. Apiiro notified affected organisations on 2 and 3 November, according to iTWire. The researchers did not test whether the secrets still worked, and they do not say whether anyone had used them. One company they contacted confirmed that its key had been live. The Cloud Security Alliance's daily briefing of 8 November adds that Check Point separately found credentials in npm packages that shipped the same file.

On the vendor side, The Hacker News reports that a bug report describing the behaviour was filed on 11 August 2025 and closed as "not planned" by an automated bot after 60 days without activity, and that four related reports were also closed by the bot, with the researchers saying none received a reply from Anthropic. iTWire reports no statement from Anthropic on the research and notes that automatic closure of an issue is not evidence of a fix. Of 16 coding agents the researchers reviewed, Claude Code is the only one confirmed to save the full approved command in a project file by default, according to The Hacker News. This page will be updated if Anthropic comments or changes the behaviour.

Timeline

How it happened: the identity attack path

1. A secret is typed into a command. A developer, or the agent on the developer's behalf, runs a command with a credential inline, such as a database client with a password argument or an environment variable set on the command line.
2. The approval is remembered verbatim. Choosing "Yes, and don't ask again" stores the full command as an allow rule in .claude/settings.local.json, so the secret is now written to disk inside the project in plain text.
3. The file reaches source control. The file is excluded only through the user's global git settings, not the project's .gitignore, so it can be committed, including in commits co-authored by the agent itself, and then pushed to a public repository.
4. History and forks keep the secret alive. Even where the file is later cleaned, older commits, forks, shared settings files and saved agent transcripts keep copies, according to the researchers.
5. Scanners miss part of it. Passwords embedded in command syntax do not match many secret-scanning rules, so 215 of the 1,122 files were flagged by neither Gitleaks nor TruffleHog. Anyone reading the repository could have found the credentials; no such use has been confirmed.

Impact

• Confirmed exposure: 2,539 secrets across 1,994 public repositories, including 379 database passwords, 43 SSH logins, 42 source control and package registry tokens and 23 AWS keys, according to Apiiro's figures as reported by The Hacker News.
• Confirmed live credential: one notified company confirmed that its exposed key had been live. The researchers did not test the rest.
• Not confirmed: any use of the exposed secrets by attackers. Neither the researchers nor the outlets report abuse.
• Potential: direct database access, server logins, package publishing and cloud account access for anyone who found the files, with the most sensitive reported cases being a database vendor's admin-level cloud key and a medical-records database owner password.
• Wider: the same risk applies to other agent folders. The researchers advise treating .claude/, .cursor/, .gemini/ and .specstory/ as secret-bearing.

What this means for NHI and AI agent security

This belongs on an NHI list because every one of the 2,539 secrets is a machine credential: database passwords, SSH logins, registry tokens and cloud keys that let software reach systems. What is new is the path they took. The leak did not come from a developer pasting a key into code or a configuration file by hand. It came from an AI agent's own permission memory, a file whose purpose is to record what the agent may do next time. That makes the agent's configuration part of the organisation's secrets estate, whether anyone planned it or not.

The general lesson is that agent tooling creates new places for secrets to land, and existing controls do not always look there. Secret scanning tuned for key formats missed passwords inside command syntax, and git ignore rules set per user did not protect shared repositories. Teams adopting coding agents should treat agent folders as sensitive, scan full git history rather than only the current branch, and keep credentials out of commands altogether by injecting them at runtime. Our Claude Code Security Guide, Coding Agent Configuration File Attacks and AI Coding Agents Security Guide cover how to set these tools up safely, and the OWASP NHI Top 10 NHI2 Secret Leakage Guide explains why leaked static secrets remain one of the most common NHI failures.

The finding also fits a long pattern on this site. Public repositories have leaked credentials for years, from the GitLab public repositories secrets study to the CISA Private-CISA GitHub leak. Coding agents add speed and volume to that pattern, because a single convenience click can write a credential into a file that is committed many times over.

Recommendations

• Rotate before you clean up. Find every copy of .claude/settings.local.json and .claude/settings.json in your organisation, check git history and forks, and rotate every secret those files have ever held, because deleting the file does not remove it from history. See our Credential Rotation at Scale guide.
• Keep agent folders out of commits and packages. Untrack the local settings file, add .claude/ and similar agent folders to the project .gitignore, and exclude them from package publication and container builds, as the Cloud Security Alliance briefing recommends. See our Claude Code Security Guide.
• Never type secrets into approved commands. Reference credentials as environment variables or fetch them from a secrets manager at runtime, and approve command patterns rather than single literal commands. See our Secrets Management Guide.
• Scan agent files and full history. Add agent folders and saved transcripts to secret scanning, scan git history and forks, and test whether your rules catch passwords inside commands such as database clients and SSH wrappers. See our Secret Scanner Rule Coverage Comparison Guide.
• Remove leaked secrets from history properly. After rotation, purge the values from repository history and ask hosting providers to clear cached views where needed. See How to Remove Secrets From Git History.
• Prioritise credentials that pair with public endpoints. A database password next to a public host name is directly usable; triage those first and check access logs for the period the file was public. See our Developer Secret Scanning Triage guide.

Frequently asked questions

How does Claude Code leak secrets to GitHub?

When a developer approves a shell command with "Yes, and don't ask again", Claude Code can save the full command as an allow rule in .claude/settings.local.json. If the command contained a password or token, that secret is stored in plain text in the project. According to The Hacker News, the file is excluded only through global git settings, not the project's .gitignore, so it can be committed and pushed to a public repository.

Were the leaked Claude Code secrets used by attackers?

No abuse has been reported. Apiiro did not test whether the 2,539 secrets still work and does not say whether anyone used them. One company it notified confirmed that its exposed key had been live. The research shows exposure, not a confirmed compromise, but any credential that sat in a public repository should be treated as compromised and rotated.

How do I check whether my repositories are affected?

Search your organisation's repositories, including history and forks, for .claude/settings.local.json, .claude/settings.json and saved agent transcripts, and look for credentials inside approved commands. Run secret scanning across full history and check manually for passwords after options such as PGPASSWORD=, sshpass -p or mysql -p, which scanners often miss. Rotate anything you find before removing it.

Related NHI Mgmt Group resources

GitLab Public Repositories Secrets Study 2025 · CISA Private-CISA GitHub Leak 2026 · Claude Code Security Guide · Coding Agent Configuration File Attacks · Leaked secret breaches

How NHI Mgmt Group can help

Coding agents are spreading faster than the controls around them, and this research shows how a routine approval click can turn into a public machine credential. NHI Mgmt Group helps security and engineering teams find where secrets live across code, pipelines and agent tooling, set rotation and ownership rules for non-human identities, and build safe defaults for AI coding agents. See our NHI and AI agent security training.

References

• The Hacker News: Claude Code's "Don't Ask Again" File Exposes Passwords and Keys in 1,122 Public Copies on GitHub (7 November 2026)
• iTWire: Claude Code approval files found exposing company secrets on GitHub, says Apiiro researchers (7 November 2026)
• Cloud Security Alliance: CISO Daily Briefing, 2026-11-08 (8 November 2026)