Claude Code Approval Files Exposed 2,539 Secrets Across Public Repositories
Apiiro found 2,539 classified credentials across public repositories, histories and agent-generated files after Claude Code stored exact approved commands in project settings. An independent test reproduced the mechanism, but public exposure still requires the file to be committed or distributed, and most credentials were not tested for validity.
A Claude Code permission option can copy an approved shell command, including any password or token written inside it, into a project settings file. Security firm Apiiro found 1,122 current public copies of that file containing credentials, while a separate hands-on test reproduced the storage behavior and showed why protection tied to one computer can fail on another.
The 30-second summary
-
What happened? Choosing “Yes, and don’t ask again” can save an exact command to
.claude/settings.local.json. Credentials embedded in the command are saved with it. - Why does it matter? Apiiro found secret-bearing Claude settings in public repositories, including database passwords, cloud keys and access tokens.
- What is the catch? The button does not upload anything by itself. Exposure occurs when the settings file is committed or otherwise distributed, and Apiiro did not test whether every detected credential still worked.
Key Number: 1,122 files. Apiiro classified that many of 104,185 public
settings.local.jsoncopies as containing at least one real secret.
How an approval becomes stored data
Claude Code asks for permission before some shell commands run. When a user approves one command permanently, the tool can record the command string as an allow rule inside a hidden .claude directory in the project. That is useful for commands the developer expects to repeat, but the rule preserves whatever was typed into the command.
If a database password appears after PGPASSWORD=, or a token is placed in a curl authorization header, the credential becomes part of the rule. The risk comes from persistence: a secret that was needed for one operation can remain in the settings file long after the command finishes.
Apiiro says Claude Code adds the local settings path to the developer’s global Git exclusions when it first creates the file inside a repository. That protects the common case on that machine. It does not add the path to the project’s own .gitignore, so the protection does not automatically travel with a clone to a second computer, a new container or a folder that becomes a repository later.
What the public-repository scan found
Apiiro searched GitHub from November 1 to 3 and downloaded 104,185 public copies of the local settings file across 103,617 repositories. Its filtering and review process classified 1,379 distinct credentials in 1,122 current files. The set included 379 database passwords, 122 Supabase service-role keys, 43 SSH logins, 23 AWS keys and other service tokens.
The broader total reached 2,539 classified secrets across 1,994 repositories after Apiiro included deleted versions in Git history, shared settings files, saved agent transcripts and related files. The company says one notified organization confirmed that its exposed key had been live. It did not use credentials, contact listed hosts or establish how many remained valid.
Standard secret scanners did not catch every case. Apiiro reports that 215 of the 1,122 current files were flagged by neither gitleaks nor TruffleHog. A password inside an ordinary-looking command may lack the recognizable prefix or format those tools use to detect cloud keys.
Independent reproduction narrows the claim
A separate test published on November 8 used fake credentials and Claude Code versions 2.1.318 and 2.1.319. The test confirmed that permanent approval copied the full command into the local settings file and that the ignore rule lived in the test machine’s global Git configuration.
On a fresh Git configuration without that exclusion, the tester asked Claude Code to commit everything. The settings file was committed before the tool warned that it contained a password. This does not prove the same sequence occurs in every workflow, but it confirms the mechanism without exposing a real credential.
A Claude Code team member said the file is intended to remain local and is automatically ignored when created. Apiiro’s response is narrower: a machine-specific ignore rule does not protect every later clone or already tracked copy. Both statements can be true.
Why this is different from a malicious extension
NewTqnia previously reported on a malicious Claude Code-branded extension that attempted to install an SSH backdoor. That incident involved injected attack code. The new finding concerns expected permission behavior interacting with commands that contain secrets and normal Git workflows.
The distinction changes the remedy. Removing malicious software is not enough here. Teams need to rotate exposed credentials, remove the file from tracking, clean relevant history only after rotation and keep secret values out of command strings by referencing environment variables or a secrets manager.
Before we overstate the result
- Apiiro’s “real secret” label means a provider-formatted key or a credential paired with a public host, not a credential proven to be active.
- The research comes from a security vendor that sells secrets-scanning products. Its large-scale counts have not been independently reproduced.
- Public exposure requires an additional step such as committing and pushing the file. The approval button alone does not publish a credential.
- The independent test used one controlled environment and fake passwords. It verifies the mechanism, not Apiiro’s entire dataset.
What developers should check now
Teams using Claude Code should search current repositories and Git history for both local and shared settings files. Any credential found should be treated as exposed and rotated before cleanup. The more durable fix is to place repository-level exclusions under version control, block secret-bearing command patterns in pre-commit and CI checks, and avoid embedding literal credentials in commands that an agent may record.
Verified topics and entities
Sources and citations4 sources
External references used to support the reporting in this article.
Published by
NewTqnia Artificial Intelligence Desk
An institutional editorial team within NewTqnia
