Cybersecurity & Privacy

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

Coding Assistant Claude Code Accidentally Exposes Passwords and API Keys in Public GitHub Repositories

The security landscape surrounding artificial intelligence tools has encountered another significant hurdle, as software security researchers reveal that Anthropic’s popular AI coding assistant, Claude Code, has inadvertently leaked sensitive credentials—including database passwords and API keys—into public GitHub repositories. The vulnerability stems from how the tool manages user permissions and automated configurations, capturing exact command-line entries in plain text and embedding them within local configuration files that frequently find their way into public version control systems.

According to a comprehensive investigation published by software security firm Apiiro, thousands of public repositories contain files that expose sensitive authentication tokens. This inadvertent data exposure highlights a growing tension in the developer tools ecosystem: the balance between maximizing developer productivity through automation and maintaining rigorous security standards. As development environments increasingly integrate autonomous or semi-autonomous AI agents, the surface area for accidental credential leakage expands exponentially, catching both independent developers and enterprise organizations off guard.

Mechanics of the Leak: How Credentials Enter Project Files

The core of the issue lies in the operational workflow of Claude Code, a terminal-based AI assistant designed to help developers write, test, and debug code. By default, Claude Code prompts the user for authorization before executing potentially impactful shell commands. When a developer encounters a frequent prompt and selects the option labeled "Yes, and don’t ask again," the assistant does more than simply execute the command.

According to Anthropic’s permissions documentation, this selection creates an allow-rule stored within a specific local project settings file: .claude/settings.local.json. This mechanism is designed to streamline future coding sessions by allowing matching commands to run autonomously without requiring repetitive manual authorization. However, the software saves these rules verbatim. If a developer typed an exact command containing a plaintext password, an API key, or a database access token during the initial prompt, that exact string—including the secret—is permanently inscribed into the JSON configuration file.

Apiiro’s security analysts confirmed this behavior while testing recent model iterations, demonstrating that secrets entered during authorized terminal operations are systematically captured in plaintext. While Claude Code attempts to prevent these local files from entering version control by automatically appending them to the user’s global Git exclusion rules upon initialization, this safeguard has critical limitations.

The global exclusion mechanism operates strictly on a single user’s local machine and does not dynamically update a project’s repository-level .gitignore file. Consequently, if a developer manually stages files, uses generic commit commands, or if the AI coding assistant itself commits changes—a phenomenon Apiiro observed in hundreds of traced repositories where Claude was listed as a co-author—the sensitive configuration file is uploaded directly to public code hosting platforms.

Scope and Scale: What Apiiro’s Audit Uncovered

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

To understand the broader implications of this design flaw, Apiiro conducted a large-scale analysis of public code repositories on GitHub. The findings paint a concerning picture of widespread credential exposure across the open-source ecosystem and enterprise software supply chains.

The security firm’s automated scanners identified over 104,000 copies of the .claude/settings.local.json file distributed across more than 103,600 unique repositories. Out of this massive dataset, approximately 1.1 percent—totaling 1,122 individual files—were found to house at least one active or historical secret, accumulating a total of 1,379 distinct sensitive values.

The nature of the exposed credentials poses severe operational and security risks to affected entities. Over a third of the uncovered secrets provided direct, unauthenticated or credentialed access to database systems, including 379 unique database passwords. Furthermore, the dataset included 43 SSH login credentials for public servers, 42 administrative tokens for major development platforms such as GitHub, GitLab, and npm, and 23 Amazon Web Services (AWS) keys.

The impact is not restricted to hobbyist projects or independent developers. Apiiro’s telemetry revealed that at least 63 distinct organizations—ranging from early-stage startups to established enterprise software vendors—had internal repositories compromised by this behavior. Among the most critical exposures identified were high-privilege administrative cloud keys belonging to a prominent database vendor and master owner passwords safeguarding sensitive medical-records databases.

Temporal Analysis and Version Control Persistence

One of the most alarming aspects of credential leakage via version control systems is persistence. Deleting a sensitive file from the current working directory of a project does not resolve a security breach because version control systems like Git are explicitly designed to maintain a historical record of all previous modifications.

Apiiro’s temporal analysis revealed that as of the study’s completion, every single file containing a exposed secret remained actively accessible on the default branches of their respective repositories. In roughly half of those affected repositories, the vulnerable files had been publicly accessible for at least 217 days.

Furthermore, historical code revisions compound the risk. Older iterations of project files across 509 repositories contained an additional 734 secrets that had been scrubbed from current operational branches but remained embedded deep within the Git commit history. Code forks further amplify the distribution of these vulnerabilities; researchers found that 211 forks originating from 74 parent repositories carried identical leaked secrets, effectively multiplying the vector for potential exploitation.

Beyond local project configurations, the investigation also highlighted risks associated with shared team settings. Apiiro discovered 298 instances—out of more than 76,000 examined copies—of the shared .claude/settings.json file containing hardcoded secrets explicitly committed by development teams as part of shared repository rules. When combining current files, historical commits, forks, and saved agent chat logs, the researchers documented a cumulative total of 2,539 secrets distributed across 1,994 unique repositories.

Comparative Analysis with Other AI Coding Agents

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

To determine whether this credential exposure vulnerability was an industry-wide systemic flaw or an isolated implementation issue, Apiiro conducted a comparative study of 16 popular AI coding assistants and terminal agents.

The evaluation revealed that Claude Code is entirely unique among its peers in this specific behavior. While other coding agents utilize various permission models, caching mechanisms, and configuration files to streamline user interactions, none of the other 15 evaluated tools were confirmed to persistently store full, verbatim approved shell commands containing raw secrets within project-level configuration files by default.

This distinction places heightened scrutiny on Anthropic’s engineering decisions regarding state management and permission caching. Critics argue that while optimizing for frictionless user experiences—such as eliminating the need to repeatedly approve routine command strings—developer tool manufacturers must implement strict sanitization layers to detect and strip sensitive parameters, API tokens, and passwords before writing authorization rules to disk.

Limitations of Traditional Secret Scanners

Mitigating the fallout from this vulnerability presents unique challenges for security operations centers (SOCs) and automated vulnerability management systems. Standard, widely adopted secret-scanning utilities often fail to detect credentials embedded within these specific configuration files.

When Apiiro ran prominent open-source secret scanners—specifically Gitleaks and TruffleHog—against the identified corpus of vulnerable files, the tools demonstrated significant blind spots. Without customized regex patterns or specialized validation rules, Gitleaks successfully flagged only 564 of the 1,122 secret-bearing files, while TruffleHog identified 643. Notably, 215 of the vulnerable files were completely missed by both scanners.

The root cause of these detection failures lies in the structural context of the data. Traditional secret scanners are engineered to recognize high-entropy strings or standardized cryptographic key formats (such as specific prefixes used by cloud providers). However, many of the secrets captured by Claude Code were passwords and tokens passed inline as arguments to standard shell utilities (e.g., following flags like PGPASSWORD=, sshpass -p, or mysql -p). To a generic secret scanner, these plaintext values frequently blend seamlessly into the syntax of ordinary command-line arguments, appearing as unremarkable strings rather than recognizable high-risk credentials.

Chronology of Disclosures and Community Reports

The discovery by Apiiro did not emerge in a vacuum; warnings regarding this exact behavior had been raised by the developer community months prior, highlighting systemic gaps in responsiveness to security bug reports.

  • August 11, 2025: A Claude Code user filed a formal bug report on the official GitHub repository (Issue #5544), detailing how approved shell commands containing sensitive API keys and authentication tokens were being systematically written in plain text to .claude/settings.local.json.
  • January 3, 2026: After 60 days of inactivity on the initial thread, an automated moderation bot closed the bug report, categorizing it as "not planned."
  • January through February 2026: Subsequent community reports highlighting the same underlying security risk faced similar fates, being systematically closed by automated bots without substantive engagement or manual intervention from Anthropic engineering teams.
  • Early March 2026: Apiiro published its comprehensive security analysis, bringing widespread public attention to the scale of the leaks and prompting renewed calls for immediate remediation from affected software developers and enterprise organizations.

Broader Industry Implications and Supply Chain Threats

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

The implications of the Claude Code data exposure extend far beyond public GitHub repositories. Security experts emphasize that configuration files left on developer workstations carry substantial risk even if they never reach version control platforms.

The .claude/settings.local.json file is stored as plain JSON directly within local project directories. Consequently, these files can easily be packaged into compiled distribution artifacts, bundled inadvertently into npm packages, captured within Docker container images, stored inside compressed zip archives, or synchronized across cloud-based file-sharing services.

Furthermore, malicious actors actively target developer endpoints to harvest high-value authentication material. In September 2025, security researchers documented campaigns involving sophisticated threats such as the Shai-Hulud malware worm, which actively scanned compromised workstations using built-in security utilities like TruffleHog to extract credentials from local development files.

Broader analysis of AI-assisted software development suggests that as organizations race to adopt generative AI tooling to accelerate engineering velocity, security governance often lags behind feature deployment. The incident serves as a critical reminder that autonomous and semi-autonomous software agents possess deep visibility into local execution environments, making robust credential management and proactive secret sanitization non-negotiable requirements for enterprise AI adoption.

Recommended Remediation Steps for Developers and Security Teams

In response to the widespread exposure, security researchers and industry analysts have outlined immediate action items for both individual developers and enterprise security operations teams.

For Developers:

  1. Prioritize Secret Rotation: Because removing a file from a repository does not erase historical version control data or forks, developers must immediately invalidate and rotate every password, API token, SSH key, and cloud credential that has ever been processed or saved within local Claude Code configuration files.
  2. Audit Project Repositories: Manually inspect project directories for the presence of .claude/settings.local.json and .claude/settings.json files to ensure they are excluded from tracking.
  3. Update Global and Local Ignores: Verify that project-level .gitignore configurations explicitly block local configuration files, ensuring that protections travel with the codebase regardless of the machine or user executing commits.
  4. Inspect Local Artifacts: Check local build environments, Dockerfiles, and packaging scripts to ensure sensitive configuration JSONs are not bundled into production distributions.

For Security Teams:

  1. Implement Custom Scanning Rules: Deploy customized regular expression rules within enterprise secret-scanning pipelines to detect inline credentials embedded within shell command strings and JSON configuration structures that standard scanners routinely overlook.
  2. Monitor Developer Endpoints: Utilize endpoint detection and response (EDR) platforms and specialized host monitoring to identify unauthorized persistence of plain-text secrets on engineering workstations.
  3. Establish AI Tool Governance: Formulate clear internal policies governing the usage of AI coding assistants, specifically regarding the approval of automated shell execution and the handling of production-grade credentials within development environments.

As the software engineering community continues to integrate advanced generative AI tools into daily workflows, the incident involving Claude Code underscores the critical necessity of embedding security by design into every layer of developer assistance infrastructure.

Related Articles

Back to top button
Snapost
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.