Cybersecurity

Claude Code AI Assistant Vulnerability Exposes Thousands of Sensitive Secrets in Public GitHub Repositories

A significant security oversight within Anthropic’s AI coding assistant, Claude Code, has resulted in the accidental exposure of thousands of sensitive credentials—including database passwords, API keys, and SSH tokens—within public GitHub repositories. Research conducted by the software security firm Apiiro has revealed that the tool’s "always allow" feature, designed to streamline development workflows, is inadvertently logging raw command-line instructions, complete with embedded secrets, into local project configuration files that are subsequently pushed to version control systems.

The vulnerability stems from the default behavior of the Claude Code assistant, specifically how it manages user permissions for shell commands. When a user interacts with the AI and selects the "Yes, and don’t ask again" prompt, the tool generates an entry in a local JSON file, .claude/settings.local.json. This file acts as a persistent permission registry, ensuring that the AI can execute specific shell commands in future sessions without requiring further user intervention. However, the documentation and implementation of this feature fail to account for the inclusion of sensitive environment variables or hardcoded passwords that are often passed as arguments within those commands.

The Mechanism of the Leak

When a developer executes a command that contains a secret—such as mysql -u user -p password or an API-specific command—and grants Claude Code permission to run it automatically in the future, the assistant saves the entire string as an "allow rule." Because this rule is saved in plain text within the project directory, it becomes a permanent part of the local codebase.

Claude Code's “Don't Ask Again” File Exposes Passwords and Keys in 1,122 Public Copies on GitHub

While Anthropic attempted to mitigate risks by configuring the tool to add this file to a global git exclusion list on the user’s local machine, the protection is fundamentally flawed. This mechanism does not prevent the file from being committed if a user manually adds it, nor does it apply retroactively to existing project structures. Furthermore, because the tool does not automatically inject the file into a project’s .gitignore file, any developer who commits the directory to a remote repository—such as GitHub—effectively publishes their secrets to the entire world. Once committed, these secrets persist in the Git history, remaining accessible even if the file is deleted in a later commit or if the repository is branched or forked.

Scope and Quantitative Findings

The research team at Apiiro conducted an exhaustive scan of public repositories to gauge the extent of the exposure. Their analysis uncovered 104,185 instances of the .claude/settings.local.json file across more than 103,000 repositories. Of these, 1,122 instances were confirmed to contain at least one hardcoded secret.

The data highlights a concerning variety of exposed credentials, including:

  • 379 database passwords, providing direct access to sensitive data infrastructure.
  • 43 SSH private keys or logins for public-facing servers.
  • 42 critical tokens for major developer platforms, including GitHub, GitLab, and the npm registry.
  • 23 AWS access keys, which could grant attackers unauthorized control over cloud environments.

The geographic and organizational distribution of these leaks is equally alarming. Apiiro identified 63 distinct organizations—ranging from small startups to established enterprise software vendors—whose repositories contained these leaked files. Among the most critical findings were admin-level cloud keys for database providers and master passwords for medical record databases, representing a significant risk to data privacy and regulatory compliance.

Claude Code's “Don't Ask Again” File Exposes Passwords and Keys in 1,122 Public Copies on GitHub

Chronology of Reported Issues

The security community has been aware of this behavior for several months, though the issue has largely remained unaddressed by the platform’s maintainers. The timeline of the vulnerability highlights a breakdown in communication between security researchers and the development team:

  • August 11, 2025: A formal bug report was filed on the official Claude Code GitHub repository, explicitly documenting that the assistant was storing sensitive commands containing API keys and tokens in the settings.local.json file.
  • Late 2025: Several additional reports were filed, mirroring the findings of the initial bug report, as developers began to realize the scope of the exposure.
  • January 3, 2026: An automated triage bot, programmed to clear inactive or "stale" issues, closed the original August bug report, marking it as "not planned" due to a lack of activity over a 60-day window.
  • February 2026: Following the publication of the Apiiro research, it was confirmed that all related bug reports had been closed by the same automated system without receiving a substantive response from Anthropic’s engineering or security teams.

Challenges in Detection and Remediation

The nature of these leaks makes them particularly difficult to detect using standard security tooling. Most automated "secret scanning" tools, such as Gitleaks or TruffleHog, are designed to identify high-entropy strings or common key formats. However, because these secrets are often embedded within shell commands, they lack the distinct signature that scanners typically look for.

Apiiro’s testing demonstrated that traditional scanners failed to identify a significant portion of the exposed credentials. While Gitleaks and TruffleHog identified 564 and 643 instances respectively, neither tool flagged 215 of the files that contained genuine passwords. This highlights a "blind spot" in current DevSecOps practices: the assumption that secrets are always formatted as distinct API tokens or environment variables.

For affected organizations, remediation is not as simple as deleting the file. Because Git maintains a comprehensive history of every change made to a repository, the secrets remain embedded in the commit logs. Researchers emphasize that rotating these credentials—changing every password, token, and key that has ever resided in the file—is the only effective way to mitigate the risk. Once the credentials have been rotated, the repository history must be scrubbed using tools like BFG Repo-Cleaner or by performing a repository rewrite to permanently purge the sensitive data.

Claude Code's “Don't Ask Again” File Exposes Passwords and Keys in 1,122 Public Copies on GitHub

Broader Implications for AI-Driven Development

The incident underscores a growing tension between the convenience of AI-powered development tools and the stringent requirements of secure coding practices. As coding agents become more autonomous, their ability to "learn" from developer commands creates a new attack vector. When an AI is granted the power to execute shell commands without human verification, the potential for accidental data leakage increases exponentially.

The fact that 16 other coding agents compared by researchers do not exhibit this specific behavior—storing full, unredacted command strings in project configuration files—suggests that this is an architectural choice rather than a necessity. The reliance on automated bots to manage issue triage further complicates the situation, as it creates a vacuum where critical security vulnerabilities can be dismissed simply because they are not discussed by the community in a way that matches the bot’s engagement thresholds.

As organizations continue to integrate large language models (LLMs) into their software development lifecycles, this event serves as a stark reminder of the "shadow security" risks associated with AI. Security teams are now urged to conduct audits not only of their application code but also of the configuration files generated by the development tools their engineers use. Without a shift toward security-first design in AI coding assistants—including mandatory masking of sensitive arguments and secure storage of persistent configurations—the industry may face an ongoing cycle of accidental credential exposure.

For now, developers who have utilized Claude Code are advised to treat their existing project configuration files as compromised, rotate all credentials that have been used within the tool, and audit their remote repositories for any evidence of committed local settings files.

Related Articles

Back to top button
Jar Digital
Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.