Claude Code Approval Files Exposed Secrets in Public GitHub Repositories, Researchers Say

A command approved for an AI coding agent can leave behind more than an execution record. If it contains a password or token, the saved permission may become another place where that credential lives.

Apiiro’s November 5 research reports secrets in 1,122 public copies of Claude Code’s .claude/settings.local.json file. The researchers did not use or test the credentials, although one notified organization confirmed its key had been live. The findings establish exposure, not a demonstrated breach of every affected system.

The Hacker News covered the findings on November 7, 2026. This is newly published research about accumulated exposure, not evidence that the files first became public that day.

What the researchers found

Apiiro’s primary research distinguishes the local permission files from its wider investigation.

These are researcher-reported measurements. Apiiro classified credentials using format and context checks, with additional review, rather than attempting authentication. Its collection covered November 1–3, 2026. A value identified as a secret was not necessarily still valid.

That distinction matters. Counting exposed credentials measures a security problem; it does not automatically count compromised accounts or successful intrusions.

How a remembered approval becomes a project artifact

Anthropic’s settings documentation confirms that selecting “Yes, and don’t ask again” for a Bash command saves an allow rule in .claude/settings.local.json.

Apiiro describes cases where that rule retains the literal command, including an embedded credential. The mechanism concerns the coding tool’s handling of approvals, rather than requiring a model to deliberately leak information.

Anthropic also documents a protection: when Claude Code first writes the local file inside a Git repository, it adds the path to the user’s global Git exclusions. That configuration belongs to the developer’s environment, not the repository’s shared .gitignore.

For teams, the practical question is therefore broader than whether a file is ignored on one laptop. What happens when the project moves to another machine, enters a different build process or already contains tracked settings?

Permission and confidentiality are separate decisions

AgentsCalling’s analysis: approving execution and approving storage should be treated as separate decisions.

A developer may understand that an agent will connect to a database. That does not mean they expect the connection credential to become part of a reusable permission rule.

Our analysis of persistent agent permissions examines a different incident, but the design question carries across: can the operator accurately explain what a lasting approval permits?

Here, that question needs an additional clause: what information will the approval preserve?

A clearer interface could show the rule being saved, identify sensitive arguments and explain its scope. These are proposed product-design improvements, not controls independently verified in Claude Code.

Why deleting the file is not the first response

GitHub’s sensitive-data guidance recommends revoking or rotating an exposed credential first.

Removing the latest file does not necessarily remove earlier commits, forks, clones or other references. GitHub also warns that rewriting history requires coordination and can disrupt collaborators’ work.

Teams reviewing their own repositories should separate three questions:

• Is the credential still capable of granting access?
• Where has the credential been copied?
• What prevents the same storage pattern from recurring?

Cleaning a repository addresses copies. Revocation addresses access. Neither should be mistaken for the other.

A practical evaluation for agent teams

A useful authorized test would use a disposable private repository and clearly fake credentials.

Ask the agent to prepare a harmless command containing a fake value, inspect the persistent approval and compare the resulting artifact with a version that references a variable. Then examine Git tracking and an archive export.

The evaluation should record what was stored, where it appeared and whether the operator understood that outcome. It should not require real production credentials or contact with exposed third-party systems.

AgentsCalling has not performed this test.

The broader lesson is straightforward: an agent’s permission system is also a data-handling system. Reviewing what it remembers deserves the same attention as reviewing what it can execute.

Reporting note: Prepared with AI-assisted research and drafting. Apiiro’s original report, Anthropic’s documentation and GitHub’s guidance were directly accessible. The Hacker News’ indexed reporting was reviewed; direct retrieval failed. No exposed credentials were tested and no independent reproduction was performed.