![Claude Code Exposed 1,379 Secrets on GitHub [2026]](https://shattered.io/wp-content/uploads/2026/11/claude-code-settings-local-json-1379-secrets-github-2026-gen.webp)
Security firm Apiiro says it found 104,185 copies of a Claude Code settings file sitting in 103,617 public GitHub repositories, and Ars Technica has now put the story in front of a wide audience. The file is .claude/settings.local.json, and of those copies, 1,122 held at least one secret. Together they carried 1,379 distinct secrets, from database passwords to cloud keys. This is the clearest example so far of Claude Code secrets leaking at scale through an ordinary developer habit.
The mechanism is mundane, which is the point. Claude Code, built by Anthropic, can remember a shell command you approved so it never asks again. If that command contained a password or token, the plain text lands in the file. Developers then commit the whole project folder, and the file goes public with it.
Below, we lay out what is confirmed, what is not, and what teams should do today. Readers following the wider AI tooling beat can find more in our AI and machine learning coverage. The short version: rotate first, clean up second, and change how you approve commands.
Don't miss new tech stories on Google
Add Shattered once in the Google app and our stories show up in your news suggestions.
What Apiiro Found in Public Claude Code Files #
Apiiro scanned public GitHub and reported 104,185 copies of the settings file. Those copies were spread over 103,617 repositories. The gap of 568 means some repositories held more than one copy, which is plausible in monorepos with several sub-projects, though the reporting does not spell out the reason.
Most of those files were harmless. Only 1,122 contained at least one secret, which works out to roughly 1.1% of the copies Apiiro counted. That share sounds small until you apply it to a corpus of this size. Across the affected files, Apiiro tallied 1,379 distinct secrets, an average of about 1.2 per affected file.
The categories matter more than the totals. Apiiro’s breakdown, as reported, lists 379 database passwords, 398 service API tokens, 43 SSH logins, 42 GitHub, GitLab and npm tokens, and 23 AWS keys. Each class opens a different door. A database password reaches customer records, an SSH login reaches servers, and a package registry token can let an attacker publish code under a trusted name.
Note what the research does not claim. Apiiro did not test whether the secrets still worked, according to the reporting. So the 1,379 figure counts exposure, not confirmed compromise. We keep that line bright throughout this piece, because the two get conflated in headlines.
How One “Don’t Ask Again” Click Writes a Secret to Disk #
Claude Code asks permission before it runs shell commands. The prompt includes an option reading “Yes, and don’t ask again.” Pick it, and the tool can save the approved command into .claude/settings.local.json so the same command runs silently next time.
That is a sensible convenience for a command like a test runner. It turns risky when the command carries credentials inline. Per the reporting, the saved command can include passwords, API keys, SSH credentials, database credentials and other secrets whenever they appear in the command text. The tool stores what you approved, verbatim.
Picture a developer asking the agent to inspect a production database. The agent proposes a connection command with the password in the URL. The developer, tired of repeated prompts, clicks the don’t-ask-again option. The password now sits in a JSON file inside the project folder.
{
"permissions": {
"allow": [
"Bash(psql postgres://app_user:[email protected]/prod -c 'select 1')"
]
}
}
The snippet above is an illustration with made-up values, not a real leaked entry. It shows the shape of the problem. The rule stores the literal command, so the secret travels with it.
Approval fatigue is the human factor
Agentic tools ask for many approvals, and people click through. We covered that dynamic in our piece on three habits against cognitive surrender, which argues engineers should keep reading what they approve. A permanent approval is the highest-stakes click in that flow, because it outlives the session and the context that justified it.
Why .gitignore Did Not Contain the Exposure #
The file is meant to stay on one machine. Reporting says Anthropic’s documentation places it in the developer’s global .gitignore list, and Claude Code’s settings docs describe the local file as the place to change a setting for yourself in one project without affecting teammates. On paper, it never reaches a remote.
Practice diverges for several reasons. A global ignore rule lives in one person’s configuration, not in the repository. A teammate with a different setup, a fresh laptop, a CI container or a quick git add . can sweep the file in. Once committed, the file is tracked, and ignore rules stop applying to tracked files.
The reporting is explicit on the consequence. A .gitignore rule does not remove a file that has already been committed. It also does not remove copies in Git history or in repository forks. Adding the rule today protects future commits only.
This is a design lesson more than a user error. Protection that depends on every contributor configuring every machine correctly will fail at the scale of 100,000 repositories. A project-level ignore entry, committed with the code, fails less often.
Breaking Down the 1,379 Secrets #
The table below compiles the figures Apiiro reported, with shares calculated against the 1,379 total. The five named categories add up to 885, which leaves 494 secrets of other types. The reporting does not itemize that remainder, so we leave it labeled as other.
| Secret type | Count | Share of 1,379 | Typical blast radius |
|---|---|---|---|
| Service API tokens | 398 | 28.9% | Third-party services, billing, data access |
| Database passwords | 379 | 27.5% | Customer and application data |
| SSH logins | 43 | 3.1% | Servers and internal hosts |
| GitHub, GitLab, npm tokens | 42 | 3.0% | Source code, package publishing |
| AWS keys | 23 | 1.7% | Cloud accounts and storage |
| Other (by subtraction) | 494 | 35.8% | Not itemized in reporting |
API tokens and database passwords dominate, together making up 777 of the 1,379. That fits the mechanism. Developers most often ask an agent to call an API with curl or open a database client, and both commands tend to carry credentials in the arguments.
The 23 AWS keys draw the most alarm, but they are the smallest named slice. Source-control tokens deserve equal attention. A single GitHub, GitLab or npm token can pivot an intruder from one repository into a whole organization or a package that thousands of projects install.
What Remains Unconfirmed #
Three claims circulate that the evidence does not support. First, nobody has shown that every public settings file contains a secret. Apiiro’s own numbers say otherwise, since 1,122 of 104,185 copies held one.
Second, reporting does not establish that the exposed secrets still work. Apiiro did not test them. Many may have been rotated, deleted or tied to throwaway test systems. Others may remain live, and nobody outside the owners can say which.
Third, reporting so far includes no Anthropic-confirmed count of compromised accounts, exploited secrets or resulting breaches. Readers should treat any headline claiming a number of victims as unverified. If Anthropic or affected companies publish figures, that picture will change.
Why press for this precision? Because the response differs. Exposure demands rotation and hygiene. Confirmed compromise demands incident response, notification and legal review. Treating the first as the second wastes effort, and treating the second as the first invites disaster.
Where Claude Code Settings Live and What Belongs in Each #
Claude Code reads settings from several scopes. Anthropic’s settings reference lists user, project, local and managed levels. Knowing which file is shared and which is personal helps you decide where a rule belongs and what Git will do with it.
| Scope | Location | Intended audience | Commit it? |
|---|---|---|---|
| User | ~/.claude/settings.json |
You, across all projects | No, it lives outside the repo |
| Project | .claude/settings.json |
Whole team | Yes, but never put secrets in it |
| Local | .claude/settings.local.json |
You, in one project | No, add it to the repo’s ignore file |
| Managed | Deployed by your organization | Every managed user | Not applicable |
The local file is the one at issue, because Claude Code writes approvals there by default when you choose the persistent option. It looks private, but it sits inside the project directory, one careless git add from public view.
Teams with managed settings have a lever the rest lack. Organizations can constrain what individual developers do, and the latest Claude Code changelog entries show Anthropic continuing to extend managed controls. Whether those controls can block persistent approvals that contain credentials is a question worth putting to your vendor contact.
How to Check Your Own Repositories Today #
Start by finding out whether the file is tracked in any repository you own or maintain. Run these from the repository root. The first command lists tracked copies, and the second searches all history, including deleted branches’ reachable commits.
git ls-files | grep -E 'settings\.local\.json$'
git log --all --full-history --oneline -- .claude/settings.local.json
git log --all -p -- .claude/settings.local.json | grep -iE 'password|token|secret|key|postgres://|mysql://'
Scan forks and mirrors too. If your organization has public forks, or if contributors copied the repository elsewhere, history cleanup on your side will not reach those copies. GitHub’s own secret scanning features can help flag known token formats, though they will not catch an arbitrary internal password.
Also check build artifacts. Security Boulevard’s write-up of the Apiiro findings warns that Docker Hub images can carry copies as well, so any image built from a directory containing the file deserves inspection. Add the file to .dockerignore as well as the Git ignore list.
Rotate First, Clean Second #
Deleting the file does not neutralize anything it held. Security Boulevard puts the order plainly: every fix starts with rotation. Anyone who copied the secret while it was public still holds it, so the credential itself must die.
A practical rotation order
| Priority | Credential type | Action |
|---|---|---|
| 1 | Cloud keys (AWS and similar) | Disable and reissue, then review access logs for unfamiliar activity |
| 2 | Source-control and package tokens | Revoke the token, check recent pushes and published package versions |
| 3 | Database passwords | Change the password, restrict network access, audit query logs |
| 4 | SSH logins | Remove authorized keys, change passwords, check login history |
| 5 | Service API tokens | Revoke in the provider dashboard, issue scoped replacements |
Order by blast radius and by how fast an attacker can monetize the key. Cloud accounts can run up bills within minutes. Package tokens can poison downstream users. After rotation, check logs for use between the date of the commit and the date of revocation.
Only then remove the file. For history, a tool such as git filter-repo can strip a path from every commit, and you then force-push and ask collaborators to re-clone. Do this knowing it cannot recall forks or caches. Rotation remains the real fix.
git rm --cached .claude/settings.local.json
echo ".claude/settings.local.json" >> .gitignore
echo ".claude/settings.local.json" >> .dockerignore
git commit -m "Stop tracking local Claude Code settings"
git filter-repo --path .claude/settings.local.json --invert-paths
Changing the Habit: Environment Variables and Narrow Rules #
Prevention beats cleanup. Security Boulevard recommends referencing environment variables, such as an API key variable, rather than embedding the literal credential in a permission rule. The stored rule then contains the variable name, not the value. The secret lives in your shell or a secrets manager.
Instead of approving a command with a pasted password, export the credential first and let the command read it. Then the persistent approval records only a reference. A reader who finds the file learns that a variable exists, which is far less useful to them.
psql postgres://app_user:[email protected]/prod -c 'select 1'
export DATABASE_URL="postgres://app_user:[email protected]/prod"
psql "$DATABASE_URL" -c 'select 1'
Review existing rules as well. The same guidance points developers to Claude Code’s /permissions command or to the settings file itself, where you can delete any rule containing a secret and tighten overly broad command patterns. Do that on every machine where you use the tool.
Teams should back personal habits with automation. A pre-commit hook that blocks any staged path matching .claude/settings.local.json takes minutes to write. A CI job that runs a secret scanner on every pull request catches what the hook misses. Layering both means a single tired click no longer decides whether a database password goes public.
Finally, treat the don’t-ask-again option as a decision to read, not a shortcut to dismiss. If the command has a credential in it, choose a one-time approval. The small friction costs seconds. A leaked production password costs weeks.
Historical Context: Config Files Keep Leaking Secrets #
This incident follows a long pattern. Environment files, cloud credential files, editor settings and CI configs have all spilled secrets onto public repositories for years. Each time, a tool created a local file, the file held something sensitive, and ignore rules failed to cover every developer.
What is new here is the authorship of the secret. In older cases, a human typed a key into a config file on purpose or by mistake. In this case, a human approved a command, and the tool persisted it. The credential reached disk through an AI agent’s workflow, a path many security teams have not yet modeled.
Other recent breaches on this site show how credentials and linked data compound risk, such as the Gnosis Pay breach that tied cards to wallets. The difference here is scale of exposure rather than a single operator’s failure. Thousands of independent developers made the same small choice.
Warnings about AI-assisted security failures are also getting louder. One of them, from a AI leader, appears in our report on a predicted AI cyber crisis. A leak like this one is smaller than a catastrophe, but it gives attackers a free map of working credentials, if any remain live.
Market Impact for Anthropic and Enterprise Buyers #
Anthropic sells Claude Code to individuals and to enterprises that care about audit trails and secret handling. A story about 1,379 exposed secrets lands directly on that pitch. We have no data showing customers leaving, and no evidence of financial damage, so any market claim here is analysis rather than measurement.
Timing adds pressure. Anthropic’s finances and listing plans draw heavy scrutiny, as covered in our explainer on what is confirmed about the Anthropic IPO. Security questions tend to surface in due diligence, and buyers of developer tools now ask where an agent stores approvals and whether those files can hold credentials.
Procurement teams will likely respond with three asks. They want a way to block persistent approvals for commands containing secret patterns. They want central policy that can disable the don’t-ask-again option. And they want clearer documentation on which settings files must never be committed.
Open-source maintainers feel a different pinch. A hobbyist who commits a settings file with a personal token exposes one account. A maintainer who commits a package registry token exposes every downstream user. The 42 GitHub, GitLab and npm tokens in Apiiro’s count are few in number, yet they carry the widest potential reach of any category in the table above.
Cyber insurers and auditors may also take notice. A named, counted, public exposure gives them a reference case when they write questions about AI tooling into renewal forms. Companies that can show central policy, rotation records and pre-commit scanning will answer those questions faster than companies that cannot.
Security vendors gain too. Secret-scanning products and pre-commit hooks now have a concrete, named case to point to. Expect Apiiro and its competitors to cite this research in sales conversations, and expect platform vendors to add the settings path to default detection rules.
Competitive View: What to Ask Any Agentic Coding Tool #
This is not a problem unique to one product. Any coding agent that remembers approvals faces the same design question. We have not tested competing tools for this behavior, so the table below is a checklist, not a verdict on any vendor.
- Where do approvals persist? Outside the project directory is safer than inside the repository folder.
- Are secrets redacted before saving? The best tools redact or refuse the rule. The worst store the command verbatim.
- Can admins disable permanent approvals? Central policy beats a per-user choice, because it does not depend on each developer’s memory.
- Is the file ignored by default? A tool that enforces the ignore rule itself beats one that relies on user setup.
- Does the tool warn on credential patterns? A warning at approval time catches the mistake at the cheapest moment.
Teams running several agents, including open-source ones, should run that checklist against each. Our walkthrough on OpenCode MCP server pooling shows how quickly agent setups multiply configuration files, and each file is another place for credentials to land.
The model underneath matters less than the plumbing around it. Our comparison of Claude and Gemini on index scores and price covers capability, but no benchmark score tells you where a tool writes your passwords.
Five Predictions for Claude Code Secrets and Agent Hygiene #
These are our own forecasts, not reported facts, and we mark confidence for each.
- Anthropic ships a guardrail. We expect Claude Code to warn on, redact or refuse to persist commands that contain credential patterns. Confidence: high, since the fix is cheap and the pressure is public.
- GitHub and scanners add the path. Secret-scanning tools will likely treat the settings file as a known high-risk location. Confidence: high.
- Enterprises demand policy controls. Procurement checklists will add a line on persistent approvals within the next few quarters. Confidence: medium.
- Copycat research follows. Researchers will scan for similar local files from other AI coding tools. Confidence: high, because the method is simple and the headline count is large.
- Confirmed abuse stays murky. Public proof tying a specific breach to these files will be rare, since victims seldom disclose root causes. Confidence: medium.
The Takeaway #
Apiiro’s count is large, but the lesson is small and actionable. A convenience feature stored plain-text commands in a file that looked private and was not. Per the reporting, 1,122 of 104,185 copies held secrets, and nobody has shown how many still work.
If you use Claude Code, audit your repositories this week. Rotate any credential that ever touched the settings file, add the path to your ignore lists, and stop approving commands that contain secrets. If you lead a team, push the same checks into pre-commit hooks and CI.
Frequently Asked Questions #
What is the Claude Code settings.local.json file?
It is a project-level file at .claude/settings.local.json that stores personal settings for one project, including approved shell commands. Anthropic’s docs describe it as the place to change a setting for yourself without changing it for teammates.
How many Claude Code secrets did Apiiro find?
Apiiro reported 1,379 distinct secrets in 1,122 files, out of 104,185 copies across 103,617 public GitHub repositories.
Were the exposed secrets still active?
Unknown. Reporting says Apiiro did not test whether they still worked, so exposure is confirmed but live access is not.
Does every public settings.local.json file contain a secret?
No. Only 1,122 of the 104,185 copies, roughly 1.1%, contained at least one secret.
Is deleting the file enough?
No. Copies can persist in Git history, forks and container images. Rotate every credential the file ever held, then clean up.
Has Anthropic confirmed any breaches from this?
Reporting so far includes no Anthropic-confirmed count of compromised accounts, exploited secrets or resulting breaches.
How do I stop Claude Code from saving secrets?
Keep credentials in environment variables so approved commands reference a variable name. Choose one-time approvals for any command containing a secret, review rules with /permissions, and add the settings path to your ignore files.