Claude Code Secret Leaks: Apiiro Finds Credentials in 1,122 Public GitHub Files

Claude Code secret leaks have put Anthropic’s saved approvals under scrutiny after Apiiro reported credentials in 1,122 public GitHub settings files. Its November 5 research describes a feature that remembers commands containing secrets. Publication requires another step: committing and pushing the resulting file.

The tension sits between a useful shortcut and the sensitive record it creates. Developers approve an operation to finish work, while the software preserves information that deserves separate protection. A decision about execution becomes a decision about storage, often without the user treating those as distinct choices.

Anthropic has acknowledged the concern, while emphasizing that the settings file should remain local. Cursor provides a useful comparison because its documentation also addresses autonomous execution and its risks. Across these products, the question is how permission systems preserve convenience without creating another place where credentials accumulate.

What the Claude Code Secret Leaks Finding Actually Measures

Apiiro’s credential exposure research examined 104,185 public copies of .claude/settings.local.json. It identified 1,379 distinct secrets in the 1,122 flagged files. The researchers did not test those credentials, so the count does not establish working access or successful intrusions.

The headline measures exposed files, rather than compromised accounts. That distinction matters for incident response, purchasing decisions, and any claim about the severity of the finding. A credential’s presence establishes a reason to investigate, while its validity and permissions determine the immediate consequences.

The underlying workflow is familiar. A coding assistant proposes an operation, the developer reviews it, and a persistent approval reduces future interruptions. The unexpected consequence appears when the saved approval retains information that the developer considered temporary.

Think of a staging database check as an illustrative scenario. The developer needs the assistant to investigate a failed connection and approves a command containing authentication information. Finishing that check does not require the credential to become a durable project artifact.

Yet an approval record can preserve precisely the information the operation needed. Its purpose sounds administrative, which makes it easy to mentally separate from passwords and access tokens. That separation becomes dangerous when reviewers assume configuration contains preferences rather than sensitive operational data.

The public repository adds another boundary. Information that was previously available to a developer’s machine becomes available to anyone who can read the project. The approval feature and the publishing workflow therefore need separate scrutiny.

It would overstate the evidence to say selecting the option automatically sends passwords to GitHub. The reported sequence involves local persistence followed by publication through version control, the system that records and shares project changes. Each stage creates an opportunity for prevention.

It would also understate the issue to describe it solely as careless committing. Product behavior determines what sensitive material exists for someone to commit. A safer publication workflow helps, but avoiding unnecessary credential copies addresses an earlier part of the problem.

The relevant change is what teams must consider during review. Agent settings deserve attention alongside application code and deployment configuration. A file can influence security through the information it preserves, even when it contains no executable program.

That expands the meaning of a sensitive change. Reviewers need to consider what a file reveals as well as what it makes the application do. Permission records sit directly at that intersection.

A Local Settings File Is a Promise With Conditions

Anthropic’s local settings documentation says persistent Bash approvals become allow rules in .claude/settings.local.json. Bash is a command shell used to run programs. Claude Code adds an exclusion to the developer’s global Git ignore configuration when it first writes the file under the documented conditions.

The documentation separately identifies .claude/settings.json as shared project configuration that teams can commit. Manually created local files require their own exclusion. These distinctions make the intended boundary clear, but they also place importance on how the file originated.

Calling a file local does not, by itself, enforce privacy. Its name communicates intent to people, while repository controls determine whether it travels with the project. Those are related protections with different failure conditions.

A global exclusion belongs to a developer’s environment. A project-level exclusion belongs to the repository’s workflow. That difference matters whenever teams expect a security convention to survive changes in machines, contributors, or development environments.

Consider a project handoff as an analytical example. The original author knows which files contain personal state and which files belong in source control. A new contributor sees the directory structure without necessarily inheriting that understanding.

The problem becomes organizational when every contributor must reconstruct the same distinction. A rule that depends on personal knowledge demands repeated attention. A rule represented in shared project policy is easier to inspect and discuss.

Neither approach eliminates the need to review what enters a commit. An exclusion is a preventive convention, while the committed change is the actual publication decision. Teams should assess both rather than assume the presence of either guarantees the other.

The terminology also deserves attention. Settings usually suggest harmless preferences such as display options or editor behavior. A permission file can carry a much more sensitive record because its contents originate in real operations.

That mismatch pressures product design. If software preserves command arguments, it should help users understand that persistence before they treat the file as ordinary configuration. The relevant warning belongs near the decision that creates the record.

There is a legitimate usability constraint here. Requiring users to inspect every implementation detail would make the assistant harder to use and encourage superficial approval. The design challenge is to surface the consequence that matters without overwhelming the operation itself.

For enterprise buyers, this becomes a concrete evaluation question. Can administrators explain which agent files are safe to share, which remain personal, and which can contain sensitive data? A product’s answers should align with the repository controls employees actually use.

Claude Code permissions explained through documentation provide the intended model. The practical test is whether that model remains understandable during everyday collaboration. Documentation establishes expectations; observable behavior determines whether teams can reliably follow them.

The Shortcut Trades Repeated Prompts for Persistent Data

The convenience of persistent approvals is easy to understand. Developers want an assistant to continue routine work without interrupting every step. A system that repeatedly requests the same decision encourages users to seek broader or longer-lasting authorization.

The central tradeoff is between fewer interruptions and the information retained to make them possible. Execution permission and credential storage deserve separate decisions, even when the interface presents them together.

A useful way to assess the design is to separate capability from data. Capability describes what the agent may do, such as run an approved development operation. Data includes the particular arguments and authentication material supplied during an execution.

Preserving capability does not necessarily require preserving every piece of data. However, removing arguments can change the meaning of a rule. A broader approval might authorize operations the user never intended, creating a different security problem.

That is why simply deleting suspicious text from saved commands is an incomplete design specification. The product must preserve the user’s intended scope while avoiding unnecessary retention. The resulting behavior also needs to remain understandable when an operation later requests permission again.

Credential references offer another design direction. A command can refer to a value supplied separately rather than embedding the value directly. That reduces the need for an approval record to contain the credential itself.

References still require care. A program might print a resolved value, an error message might reveal it, or another artifact might preserve the output. Avoiding a literal password in one record reduces exposure without establishing complete protection.

This is where the story becomes relevant beyond a particular button. Agent software produces records to support continuity, debugging, and collaboration. Every record should have a defined purpose, audience, and retention policy proportional to its contents.

The assistant’s apparent memory can obscure those questions. Users experience a conversation that continues work, while the implementation may create files with different sharing rules. Product teams need to make the consequential boundaries visible.

Cursor’s background agent security documentation supplies a useful comparison. It describes isolated virtual machines, internet access, and automatic terminal execution. It also warns that malicious instructions can lead to data theft through prompt injection, where untrusted content redirects an agent’s behavior.

That comparison does not establish that Cursor shares Claude Code’s reported approval-storage behavior. It shows that competing designs distribute responsibility differently across execution, isolation, and user review. Buyers should compare those mechanisms separately instead of selecting a product by its approval mode alone.

Isolation constrains the environment in which an operation runs. Approval decides whether an operation proceeds. Credential handling determines what sensitive data enters the environment and what records remain afterward.

These controls reinforce each other when their boundaries are explicit. They become confusing when a successful decision at one layer is treated as evidence that every other layer is safe. An authorized operation can still leave an inappropriate record.

Claude Code security risks therefore deserve evaluation at the workflow level. The useful question is what information an approved task creates, where that information persists, and who can later retrieve it.

Anthropic Acknowledges the Gap, but Auto Mode Is Not a Fix Certificate

Boris Cherny, from the Claude Code team, addressed the report in the permission safety discussion. He said Claude Code historically lacked secret scrubbing and recommended auto mode and repository secret scanning. He also described possible safeguards for prototyping, including basic secret detection.

A reader challenged whether auto mode could still reach the problematic approval path. Cherny acknowledged that observation. His comments establish an active response, but they do not establish that a comprehensive fix has shipped.

A proposed safeguard needs verification against the failure it is supposed to prevent. Reducing manual approvals and preventing credential persistence are related goals, with different acceptance criteria. Evidence for one should not substitute for evidence about the other.

The skeptical view is straightforward. If a sensitive operation still creates an approval record containing a credential, changing the default execution mode leaves that pathway relevant. A response must address the resulting artifact as well as the frequency of prompts.

There is also a reasonable argument behind Anthropic’s emphasis on fewer permission interruptions. Repeated prompts can consume attention without producing careful review. Improving that experience is worthwhile, provided the improvement does not become a blanket security claim.

The disagreement is partly about where enforcement belongs. Some users want fixed restrictions that hold regardless of an agent’s interpretation. Others favor automatic evaluation that can distinguish routine activity from sensitive operations.

Those approaches answer a different question from whether saved records contain passwords. A strict execution boundary can coexist with excessive data retention. An automatic reviewer can reduce interruptions while still needing explicit rules about what gets written to disk.

Enterprise evaluation should keep those questions separate. A buyer can value automatic task execution and still require predictable storage behavior. The product should demonstrate both using observable results rather than asking customers to infer one from the other.

A credible verification exercise would use artificial credentials in a controlled project. It would inspect the approval record and other resulting artifacts after the operation. It would also examine behavior when a sensitive local file is already tracked.

Those are proposed evaluation conditions, rather than claims about tests completed by Anthropic. They describe the evidence needed to distinguish a promising response from a demonstrated improvement. Published results would let customers judge the scope of any change.

Claude Code secret leaks also expose a communication challenge. Advising users to enable another control is useful, but it leaves open which responsibility the product itself will assume. Clear release notes should explain both the new protection and the remaining conditions.

The fairest conclusion is limited and actionable. Anthropic recognizes the concern, users have raised relevant edge cases, and the effectiveness of proposed changes requires observation. Neither dismissal nor a declaration of complete remediation fits the available evidence.

Security Teams Inherit a Different Kind of Repository Review

For security teams, the immediate pressure concerns visibility. Application reviews often concentrate on code that runs in production. Agent-generated settings can create exposure before the application itself changes behavior.

Review needs to follow sensitive information across the development workflow. A configuration file deserves scrutiny based on its contents and destination. Its administrative purpose does not make the information inside it harmless.

GitHub’s push protection blocks supported secret detections before publication. Its documentation distinguishes provider-specific, generic, custom, and AI-detected patterns, with configuration requirements that vary. Teams therefore need to verify the coverage they have enabled rather than assume every credential will be caught.

A scanner’s presence and a scanner’s demonstrated coverage are different forms of evidence. A recognizable service token and an ordinary password embedded in a command present different detection challenges. Testing with artificial examples can reveal whether the configured system recognizes the patterns a team actually uses.

This changes the conversation between developers and security staff. The developer needs a workflow that continues to function. The security team needs evidence that sensitive values do not quietly enter material intended for sharing.

The shared objective should be a repeatable boundary. Personal agent state should have an explicit destination, shared configuration should have a clear review standard, and detected credentials should reach someone who can revoke them.

An incident response must also separate containment from cleanup. GitHub’s sensitive data removal guidance prioritizes revoking or rotating exposed credentials. It explains that historical removal requires coordination and that copies can remain in clones, forks, and other references.

That order reflects the difference between a credential and the document containing it. Editing a document changes what readers see in that location. Revocation changes whether the credential continues to authorize access.

For a team under pressure, visible cleanup can feel like completion because the offending file disappears from the latest view. The relevant security outcome is whether the exposed value retains authority. Historical cleanup and access review address additional consequences.

Responsibility becomes harder when the person discovering the record cannot identify its owner. A developer might recognize a project name without knowing which system issued a token. Clear ownership shortens the path from detection to effective containment.

Teams also need a way to preserve the lesson without preserving the secret. An incident note can describe the affected workflow, the responsible service, and the preventive change. It should avoid copying sensitive values merely to make the explanation concrete.

That distinction applies to a searchable knowledge base as well. Useful engineering knowledge includes approved procedures and explanations of past failures. Credentials belong in systems designed to manage access, rather than general reference material.

Claude Code security risks are easier to govern when the response has named owners. Developers can explain the task, platform teams can enforce repository conventions, and service owners can replace access credentials. Security staff should not have to reconstruct all those relationships during an investigation.

The practical organizational change is a broader review perimeter. Teams need to inspect what the assistant leaves behind alongside what it edits. That makes persistent agent state part of normal engineering governance.

What Would Demonstrate That the Exposure Path Is Closing?

The next useful evidence should arrive in product behavior, repository controls, and remediation outcomes. These signals address different parts of the reported sequence. Together, they can show whether the original exposure pathway becomes harder to reproduce.

Progress should be measured by prevented persistence and reduced credential authority. Announcement language alone cannot establish either result. The strongest evidence will connect a specific safeguard to an observable change.

First, watch for a documented Claude Code release that changes how sensitive approvals are stored. The decisive detail is what happens when an otherwise legitimate command contains authentication material. A release should explain the resulting record and the circumstances that still require user intervention.

Evidence that synthetic secrets no longer appear in saved approvals would strengthen the case for a meaningful product improvement. Evidence that the same values remain under an alternative permission path would narrow that conclusion. Both outcomes are more informative than a general statement about safer automation.

The scope of testing matters as much as the headline behavior. A fresh project and a repository with an existing tracked settings file represent different starting conditions. A clear account should identify which conditions the protection covers.

Second, watch for repository controls that demonstrate coverage of agent configuration and command-embedded credentials. This includes clear exclusion policies and tested secret detection. The meaningful outcome is whether an attempted publication is stopped or routed into effective review.

A policy document alone leaves execution uncertain. A controlled exercise showing that artificial credentials trigger the expected response provides stronger evidence. Repeated misses would weaken confidence in scanning as a compensating control.

This signal also matters for competitors. Vendors can describe execution environments differently while still needing to explain their retained artifacts. Clear documentation of generated files, sharing boundaries, and credential handling would make comparisons more useful for buyers.

Third, watch for remediation reporting that distinguishes files removed from credentials invalidated. Repository appearance is easy to observe, while continued access requires information from the responsible service. Credible follow-up should keep those outcomes separate.

Apiiro’s results have not been independently reproduced here, and its collection should not be treated as a random sample of all Claude Code projects. The reported population consists of publicly discoverable files. That limits conclusions about the prevalence of exposure across the broader user base.

Those limits leave the central engineering concern intact. A feature that preserves operational context needs a clear policy for sensitive data. Users should be able to understand that policy without reconstructing the implementation during a deadline.

For teams assessing Claude Code secret leaks, start with the approval record your workflow actually creates. Use synthetic credentials to examine what persists, then verify which controls prevent that material from reaching a shared repository. Assign ownership before a real exposure forces the issue. Preserve the findings as procedures that colleagues can follow without reproducing sensitive values. When genuine credentials appear in shared material, make their remaining authority the first question for the responsible service owner. Ask vendors for evidence that addresses storage as well as execution. The most useful next review is one that answers a concrete question: after an approved task finishes, what sensitive information remains, and who can get it?