Did Claude Code approval files expose GitHub secrets? A vendor audit found 2,539—but did not test them
Apiiro scanned public repositories and classified 2,539 distinct credentials across 1,994 repositories, including 1,379 in current Claude Code local-settings files. The study shows a preventable exposure path, not proof that every credential still worked or had been abused.
The short version
- What happened
- Apiiro found 1,122 secret-bearing files among 104,185 public copies of .claude/settings.local.json, or about 1.1%, and counted 1,379 distinct secrets in those current files.
- Who it affects
- Developers may unknowingly create a durable plaintext copy when approving a command containing a password or token; checking local agent settings should be part of credential hygiene.
- What remains unproven
- Apiiro is a security vendor with a commercial interest in agent-security risks, and the collection has not been independently replicated.
Keep in mind
Apiiro is a security vendor with a commercial interest in agent-security risks, and the collection has not been independently replicated.
The researchers did not use credentials or contact hosts, so validity and exploitation are largely unknown; one organization confirmed one key had been live.
An LLM reviewer helped classify masked candidates, but no external labelled test set or classifier precision and recall are published.
Historical coverage was incomplete and source-specific denominators differ, so the 2,539 total should not be treated as a prevalence rate across all repositories.
Public GitHub results do not measure private repositories, developer laptops, other coding agents or every way local files may be shared.
Multi-source analysis · 3 linked sources. Primary analysed source date: 5 November 2026. Earliest linked supporting source: 4 December 2025.
Read the full report · 11 min The evidence, methods, implications and limitations
The answer: public files contained credential-shaped data, but the audit did not prove widespread compromise
Security company Apiiro reports that a convenience feature in Claude Code can preserve an exact approved shell command inside a project-local settings file. If the command contains a database password, cloud key or API token, that value can be stored with the permission rule. The immediate disclosure happens only if the file is then tracked and pushed, packaged or otherwise shared. The model does not automatically publish every local setting, and the research does not show that every Claude Code user is affected.
The vendor searched public GitHub repositories from 1 to 3 November and downloaded 104,185 copies of .claude/settings.local.json from 103,617 repositories. It classified 1,122 files, about 1.1%, as containing at least one real secret under its definition. Those current files held 1,379 distinct values: 636 provider-format keys and 743 passwords or tokens placed beside a public host. Apiiro says 379 were database passwords, 122 were Supabase service-role keys, 43 were SSH credentials and 23 were AWS keys.
Those numbers demonstrate that sensitive-looking values were publicly exposed in a repeatable workflow. They do not demonstrate that 1,379 systems were accessible. Apiiro deliberately did not use the credentials or contact the listed hosts. A value counted as real when it matched a known provider format or appeared with a public host after filtering and review. One notified company confirmed that its key had been live, but that single confirmation cannot be generalized to the whole collection.[1][2]
How an approval can become a durable secret copy
Claude Code asks before running many shell commands. Selecting a standing approval writes an allow rule so the same command can run again without another prompt. Anthropic's documentation confirms that project-local permissions are stored in .claude/settings.local.json. Apiiro's central observation is that an exact approval can preserve the complete command string. A connection command containing a literal password therefore creates another plaintext copy of that password inside the project directory.
Anthropic documents a safeguard for the common case: when Claude Code writes the local file inside a Git repository, it adds a pattern for that file to the user's global Git excludes. Global excludes are local to that account and machine. They do not travel with a cloned repository, protect a directory that becomes a repository later, override an explicitly tracked file or remove an old commit. Apiiro found that 539 of 1,105 traced repositories with a current secret included a Claude-coauthored commit that changed the settings file, although a coauthor marker does not establish who decided to push it.
The issue predates this audit. A public report filed in Anthropic's repository in December 2025 described sensitive tokens in the same settings file and asked for secure storage and repository-level ignore protection. That is useful corroboration of the mechanism, but it is still one user's report. Apiiro's contribution is the much larger public-repository count, the classification method and an attempt to quantify what ordinary secret scanners missed.[1][2][3]
The distinction that matters
How one approval can become a public credential
The exposure requires several steps. Separating them avoids blaming the model for every repository mistake while still showing where controls can fail.
Command
A literal secret enters a shell command
The value exists in process text
Approval
The exact command is saved as an allow rule
A second plaintext copy is created
Repository
The local file is tracked or packaged
History and forks can preserve it
Response
Rotate, then untrack and clean
Deleting alone is insufficient
What 2,539 measures—and why it is larger than the headline file count
The 2,539 figure is not the number found in current local-settings files. Apiiro counted 1,379 distinct secrets in the 1,122 current files. It then examined more places where agent activity can persist. Earlier versions of deleted or changed files added 734 secrets across 509 repositories. Shared .claude/settings.json files, which teams may intentionally commit, contributed additional values. The vendor also searched saved agent transcripts, memory files, handoff notes and Copilot auto-approval settings. Across those sources, it reports 2,539 distinct secrets in 1,994 repositories.
The denominators differ by source. Apiiro says it downloaded all 76,011 shared settings files returned by its search and found secret-bearing values in 298. It inspected 2,523 transcript files and found affected files in 87 repositories. File-history checks covered 43,120 repositories rather than every repository in the current-file collection, so the vendor describes the historical count as a floor. Memory, handoff and Copilot files were classified by rules alone, not the full secondary review used for the main collection.
Forks make deletion an incomplete response. The audit found 211 forks of 74 repositories carrying the same secrets, while every current secret-bearing local file remained on a default branch at the vendor's 2 November snapshot. Half of the affected repositories had first committed the file at least 217 days earlier. That measures persistence, not necessarily credential lifetime: keys may have expired or been rotated without the public file changing.[1]
The method reduces obvious false positives but remains vendor-reported research
GitHub code search caps results, so the researchers split queries by file size until each slice stayed below the limit, then downloaded the returned files. Provider-pattern rules identified keys with recognizable formats. For generic passwords and tokens, a value counted only when a public host appeared on the same line. Filters removed placeholders, common defaults, private hosts, public-by-design keys, expired tokens and provider tokens whose built-in checksum failed.
After those rules, 2,774 distinct candidates remained. Apiiro says an independent language-model reviewer examined each value in masked context using a written rubric, and 2,539 counted only when the rules and review agreed. Masking is a sensible way to reduce disclosure during review, but the paper does not provide an external replication, a manually labelled test set or precision and recall estimates for the classifier. Agreement between a ruleset and an LLM is not equivalent to confirming a credential with its issuer.
Apiiro sells application and agent security products, giving it a commercial interest in the problem it describes. The research still publishes unusually detailed denominators, search dates, filters and limitations. Readers should therefore treat the counts as a documented vendor audit that can be independently tested, not as a neutral census of every coding-agent repository or proof of a product breach. Anthropic's documentation supports the storage mechanism but does not endorse Apiiro's counts or conclusions.[1]
Why ordinary secret scanning missed some of the files
Apiiro ran gitleaks and TruffleHog over the 104,185 current local-settings files without credential verification. Gitleaks flagged 564 of the 1,122 secret-bearing files and TruffleHog flagged 643; 215 were flagged by neither. The difficult cases were often ordinary passwords embedded in a shell command rather than keys with a recognizable prefix. A detector designed for a long provider token can miss a short database password following PGPASSWORD= or a password passed to an SSH helper.
This does not mean those scanners are ineffective. Their results depend on configuration, versions, custom rules and whether verification is enabled. The experiment shows a specific coverage gap under Apiiro's run conditions. Security teams can use that finding to add contextual rules for agent folders, exact command approvals and connection strings, while expecting more false positives that require human review. A scanner should support prevention and response rather than become the only control.
The broader lesson is that agent-generated artefacts deserve the same handling as environment files and deployment notes. Transcripts, memories and handoff documents can contain commands copied from a debugging session. Retention and sharing policies should cover those files explicitly. Tools should minimize stored command detail, redact likely credentials and make the storage location obvious, but developers and organizations also remain responsible for keeping literal secrets out of command lines and version control.[1]
What developers and security teams can do without waiting for a product change
Apiiro advises teams to search current repositories and history for .claude/settings.local.json and shared settings files. If a credential appears, rotate it before cleanup because deleting a file does not invalidate the value or remove forks, clones and old commits. Untrack the local file, add an explicit repository-level ignore rule where appropriate and inspect the allow list for commands containing connection strings, authorization headers or literal passwords.
Future commands should reference secrets through environment variables or a managed secret store rather than placing values directly in the command that an agent may record. Pattern approvals can avoid preserving one literal invocation, but they expand what may run without another prompt and therefore need narrow scope. Teams should review standing approvals, protect branch and release processes, scan build contexts and packages, and record which credentials were rotated and which histories were cleaned.
Organizations should not search public code in ways that expose or test other people's credentials. The defensible workflow is to inspect repositories they own, use provider and Git-host secret alerts, notify affected maintainers through established channels and preserve evidence without copying sensitive values into tickets or chat. The practical human impact is clearest for developers and incident responders: a seemingly harmless approval can create another secret-bearing artefact that survives long after the original debugging task.[1][2]
Why this is Latest, not Breaking—and what would change the assessment
Apiiro published the research on 5 November and collected the main data before then. It is consequential because public credentials can enable unauthorized access and because the workflow affects a widely used coding agent. It is not a newly disclosed active compromise with a time-critical instruction inside the portal's verified 24-hour Breaking window. Marking it Breaking on 8 November would misdate an older source and imply urgency the evidence does not establish.
Confidence would rise if an independent team reproduces the GitHub collection with published queries, releases a safely redacted labelled sample and reports precision and recall. Provider-side confirmation could establish how many keys were active when found, while responsible incident records could distinguish accidental exposure from attempted or successful misuse. Anthropic could also clarify whether it will redact exact approvals, warn when a command contains a probable secret or add portable repository-level protection without disrupting legitimate local settings.
The assessment would weaken if replication finds substantial double-counting, poor classification precision or many values that were demonstrably invalid before publication. For now, the evidence supports a narrow but useful conclusion: exact command approvals created a repeatable path for secrets to enter project files, and thousands of credential-shaped values were present in public repositories under the vendor's documented method. It does not support claiming that Claude Code itself exfiltrated those values or that every exposed credential was successfully abused.[1][2]
Keep following the evidence
Join The Impact Brief founding list for selected AI reports, their effect on people and the evidence limits. Read a sample first.
Continue the story
Read next
Continue exploring coding agents: compare the finding and its evidence limits.
A coding agent can look normal while a backdoored extension steals credentials
CERT-EU modified two legitimate packages in an isolated lab. A routine phrase triggered background data collection outside the model's visible tool calls, showing why plugin controls must cover the whole agent environment.
Read the next reportExplore the full source and evidence record
What this means for people
- Developers may unknowingly create a durable plaintext copy when approving a command containing a password or token; checking local agent settings should be part of credential hygiene.
- Security teams need repository and history searches that cover agent folders and passwords inside commands, while avoiding unsafe attempts to validate credentials they do not own.
- People whose data sits behind an exposed database could be affected if a valid credential is abused, but the study did not measure access, data loss or individual harm.
Global context
The audit concerns globally accessible public repositories and organizations in multiple sectors, but it is anchored in GitHub search and Claude Code's documented settings behaviour. Other agents store approvals differently. The transferable question is whether agent tools minimize, label and protect the commands, transcripts and memories they persist—and whether organizations treat those artefacts as secret-bearing data.
What the evidence does not yet show
- Apiiro is a security vendor with a commercial interest in agent-security risks, and the collection has not been independently replicated.
- The researchers did not use credentials or contact hosts, so validity and exploitation are largely unknown; one organization confirmed one key had been live.
- An LLM reviewer helped classify masked candidates, but no external labelled test set or classifier precision and recall are published.
- Historical coverage was incomplete and source-specific denominators differ, so the 2,539 total should not be treated as a prevalence rate across all repositories.
- Public GitHub results do not measure private repositories, developer laptops, other coding agents or every way local files may be shared.
What to watch next
- Independent replication of the public-repository counts and classification accuracy.
- A documented Anthropic product response or change to exact-command storage and portable ignore protection.
- Provider-side confirmation of how many identified credentials were active, rotated or abused.
- Secret-scanner rules designed for passwords embedded in agent commands, with measured false-positive rates.
- Whether repositories and package build systems adopt explicit policies for agent settings, transcripts and memory files.
Living evidence record
Impact record IAI-019DE9J
Evidence stage
Observed
Confidence
Corroborated
Reporting basis
Multi-source analysis
Independent or research support
Present
Record status
Monitoring
Last checked
8 November 2026
Source trail
3 direct sources across 2 source types.
People impact
Documented in this record.
Uncertainty
Limits and next checks are explicit.
Stages describe the evidence available—not whether a technology is good or bad. See the public method.
Evidence trail
Sources used for this report
Links checked 8 November 2026
Research question, topics and regions
Apiiro's read-only audit of secrets stored in public coding-agent settings, repository history and related files
Topics: Coding agents · Credential security · GitHub · Developer tools · Secret scanning
Regions: United States · Global
This report is labelled multi-source analysis. We summarise and analyse source material in our own words; company statements remain attributed claims until independently supported. Translated summaries preserve the meaning of the original source and link back to it. Read our editorial standards.
Reader commentary
What does this mean where you are?
Tell us what you have seen at work, in your community or in everyday life. A question is welcome too. No account is needed; we review notes before publishing them.
Explore commentary across the portal →Published reader notes
0No published reader notes yet. You can start the evidence-led discussion above.
Prefer a private correction or response? Contact the newsroom.