Claude Code’s permanent approval option can preserve an entire shell command in a project settings file, including a password, token or connection string typed directly into that command. Security company Apiiro says it found 1,379 distinct secrets in 1,122 public copies of .claude/settings.local.json on GitHub.
The research, published November 5, covered 104,185 public copies of the file across 103,617 repositories. Apiiro did not test the credentials, so the count does not prove that every key was still active or had been abused. One organization contacted by the researchers confirmed that its exposed key had been live.
Developers who have used “Yes, and don’t ask again” should check both the current file and Git history. Deleting the file is not enough if it has already been committed. The immediate priority is to revoke or rotate every credential it has held, then remove the material from the repository and prevent the file from returning.
How Claude Code’s approval file can hold a secret
Anthropic’s settings documentation explains that a standing approval for a Bash command is written as an allow rule in .claude/settings.local.json at the repository root. That is useful for avoiding repeated prompts, but the stored rule may contain the literal command.
A command such as PGPASSWORD=example psql -h db.example.com, sshpass -p example ssh user@host or a curl request with an authorization header puts the secret directly in the command line. If that exact command becomes an approval rule, the same value can remain in the JSON file long after the task finishes.
Claude Code tries to keep the local settings file out of commits. The first time it writes the file in a Git repository, it adds **/.claude/settings.local.json to the machine’s global Git excludes file. The safeguard is local to that computer, however. It does not travel with the repository to a new workstation or container, does not protect a file created by hand, and does not stop changes to a file that Git already tracks.
Apiiro found that a Claude-co-authored commit had changed the file in 539 of 1,105 affected repositories for which it traced commits. The researchers also found 734 secrets only in older versions of the file, showing why a clean current branch does not settle the question.
What Apiiro counted, and what it did not prove
The 1,379 values included 379 database passwords, 122 Supabase service-role keys, 103 Supabase account tokens, 43 SSH logins, 42 GitHub, GitLab or npm tokens, 23 AWS keys and six private keys. Apiiro counted provider-formatted keys and passwords or tokens paired with a public host, while filtering placeholders, common defaults, local hosts and values designed to be public.
The company used read-only GitHub code and commit search from November 1 through November 3. Its broader review of Git history, shared Claude settings and saved agent transcripts counted 2,539 distinct secrets in 1,994 repositories. The classification process included rules, two conventional secret scanners and a review of masked candidates by an independent language model.
Those methods create an important limit: “real secret” means the value looked like a credential in context, not that Apiiro logged into an account with it. Independent coverage from iTWire likewise noted that the research establishes exposure risk, not a demonstrated breach for every value.
The scanner results also show why a normal repository scan may not catch everything. Gitleaks flagged 564 of the 1,122 affected files and TruffleHog flagged 643; 215 files were missed by both. Provider keys often have recognizable prefixes and formats. An ordinary password placed after mysql -p or sshpass -p may look like an unremarkable word inside a shell command.
Check the current repository and its history
Start from the root of each repository where Claude Code has run. These read-only commands show whether either local or shared settings files are tracked and whether the local file appears anywhere in reachable history:
git ls-files -- '.claude/settings.local.json' '.claude/settings.json'
git log --all --full-history -- '.claude/settings.local.json' '.claude/settings.json'Next, inspect the permissions.allow entries in the current files. Look for connection strings, authorization headers, provider keys, passwords assigned to environment variables, sshpass, database client password flags and tokens embedded in URLs. Do not paste the output into a ticket, chat or shared document; that would create another copy of the credential.
If the history command returns commits, review the relevant patches in a controlled terminal:
git log -p --all -- '.claude/settings.local.json' '.claude/settings.json'Teams should repeat the search in their GitHub organization, including archived repositories and forks. They should also examine agent transcripts, deployment notes and other checked-in tool configuration. Apiiro found exposed values in shared .claude/settings.json files, agent chat exports, memory files and handoff notes, not only in the local approval file.
If you find a credential, rotate it before cleanup
Treat every credential that reached a commit as exposed. Revoke or rotate it at the issuing service, update legitimate applications, and review the service’s audit logs for unexpected access. Prioritize credentials tied to production databases, cloud administration, package publishing, source control and public hosts.
Only after rotation should the team remove the rule and stop tracking the local file:
git rm --cached .claude/settings.local.jsonAdd .claude/settings.local.json to the repository’s own .gitignore, commit both changes and confirm with git ls-files that the file is no longer tracked. A repository-level ignore rule follows the project to other machines, unlike a developer’s global exclude file.
For sensitive material that must be purged from history, GitHub recommends git-filter-repo and a coordinated history rewrite. Its sensitive-data removal guide warns that old commits can remain in forks, clones, cached views and pull-request references. History rewriting can also disrupt signatures, open pull requests and collaborators’ clones. Rotation is therefore the security fix; rewriting is the cleanup step.
Prevent the same leak from returning
Do not put secret values directly in commands that an agent may approve, log or replay. Pass a reference such as $DATABASE_URL from a credential helper or secrets manager, so the saved command contains the variable name rather than its value. Prefer short-lived, narrowly scoped credentials over durable administrative keys.
Review standing approvals and keep them narrow. A reusable rule for a known test or build command is less likely to capture sensitive data than a literal one-off deployment or database command. Teams can also add the local settings path to shared .gitignore templates and pre-commit checks.
Secret scanning should cover the full Git history and agent-generated files, with detection for password-bearing command patterns as well as recognizable API-key formats. GitHub’s push protection or another scanner remains useful, but the Apiiro results show that format-based detection cannot be the only control.
Anthropic’s head of Claude Code, Boris Cherny, responded to the report on November 7. In an update added by Apiiro, he said the team was considering stronger auto-mode handling and built-in basic secret scanning, but no shipped fix was announced in the report. Until the behavior changes, developers should treat saved agent approvals as credential-bearing configuration and audit them accordingly.
