Claude Code Exposes Developer Passwords and Keys on GitHub

Software security firm Apiiro has identified 1,122 public copies of Claude Code configuration files on GitHub that expose passwords and API keys. When developers approve shell commands using the "Yes, and don't ask again" option, Anthropic's AI coding assistant writes the commands word-for-word into a project settings file. The exposed credentials include database passwords, SSH logins, and cloud provider keys across more than one thousand repositories. Malaysian organisations that use AI coding assistants should examine their repositories for exposed credentials and report suspected incidents to Cyber999 under MyCERT.

Key Facts

How Does Claude Code Store and Expose Sensitive Credentials?

When a user selects the "Yes, and don't ask again" option, Claude Code saves the exact executed command inside a project settings file named .claude/settings.local.json. If sensitive tokens or passwords were typed directly into the prompt, the assistant writes those secrets in plaintext, which subsequent git commits frequently push into public repositories.

By default, Claude Code requests confirmation before executing most shell commands. If a developer approves a specific command permanently rather than an abstracted pattern, the software stores an allow rule containing any embedded authentication parameters. While Claude Code attempts to add the filename to a user's global git excludes file upon its first creation, this exclusion resides solely on that specific machine. It does not update the repository's own .gitignore file, meaning the exclusion does not travel with the project. In 539 of 1,105 traced repositories, commits listing Claude as a co-author modified the file, indicating the tool frequently commits the file itself. Furthermore, of 16 coding agents examined by researchers, Claude Code is the only tool confirmed to save approved commands verbatim into a project file by default.

Claude Code is the only tool among 16 evaluated coding agents that saves approved commands in a project configuration file by default.

What Data Has Been Exposed in Public Repositories?

Security researchers identified 1,379 unique secrets across 1,122 publicly accessible configuration files, including database credentials, server logins, and major cloud infrastructure tokens. Discovered credentials belong to 63 organisations and include administrative keys for database vendors as well as the owner password for a healthcare database, presenting severe operational risks.

Apiiro scanned 104,185 copies of .claude/settings.local.json across 103,617 repositories, finding that approximately 1.1% contained at least one secret. More than a third of the exposed items provide direct access to databases, encompassing 379 database passwords. The leak also features 43 SSH logins for public servers, 42 access tokens for platforms including GitHub, GitLab, and npm, and 23 Amazon Web Services (AWS) keys. Commit history preserves an additional 734 secrets across 509 repositories where the active file was subsequently deleted, while 211 repository forks replicated the exposed secrets. When combined with team-shared .claude/settings.json files and agent chat logs, the total reaches 2,539 secrets across 1,994 repositories. Automated scanners like Gitleaks and TruffleHog failed to detect 215 of the vulnerable files because passwords embedded within commands do not match standard cryptographic key patterns.

Database passwords constitute more than one-third of the credentials found exposed in the public Claude Code configuration files.

Have the Discovered Vulnerabilities Been Addressed?

Anthropic has not replied to cited bug reports highlighting the issue, and automated bots closed four separate user submissions after periods of inactivity. While researchers noted that one notified company confirmed its leaked API key was live, the investigation did not verify whether any third parties had exploited the exposed credentials.

Users reported this credential-saving behaviour as early as 11 August 2025, warning that authentication tokens were recorded verbatim inside local settings files. An automated bot closed that report as "not planned" on 3 January 2026 after 60 days without activity, and three subsequent reports cited by researchers were closed by the same mechanism. All repositories identified by researchers still hosted the vulnerable files on their default branches as of Monday, with credentials remaining accessible for at least 217 days in half of those repositories. Files retained strictly on local developer environments also remain vulnerable to local discovery, as seen in September 2025 when the Shai-Hulud worm used automated scanners to harvest secrets from infected developer machines.

Four separate bug reports documenting credential storage in Claude Code settings files were closed by an automated bot without vendor resolution.

What Should You Do?

No official software update or vendor patch has been released. Security teams and developers should implement the following hardening and remediation measures recommended by researchers:

• Rotate every password, token, and key that has ever appeared in a Claude settings file before undertaking cleanup, as git history preserves previously committed data.
• Search GitHub organisations for .claude/settings.local.json and .claude/settings.json, including past git commit histories across all repositories.
• Stop tracking local configuration files by running git rm --cached .claude/settings.local.json and adding the path to the repository's .gitignore file.
• Open local settings files on developer workstations and delete every approved command rule that contains sensitive credentials.
• Reference credentials via environment variables from a secrets manager (such as $DB_URL) instead of passing raw secrets in terminal commands.
• Approve broad command patterns (such as Bash(npm run:*)) rather than approving individual static commands containing secrets.
• Configure pre-commit hooks and continuous integration scanning to inspect agent directories, including .claude/, .cursor/, .gemini/, and .specstory/, ensuring scanners flag passwords inside commands.

Common Questions

Does deleting the configuration file from GitHub fix the leak?

No. Deleting the file from a repository's current branch leaves the plaintext credentials exposed in previous git commit histories and across downstream forks. Security teams must rotate every exposed secret first, remove the cached file from tracking, and ensure local copies are scrubbed.

Why did standard secret scanners miss these credentials?

Conventional secret scanners look for structured key formats rather than plain strings inside terminal commands. Passwords supplied directly via parameters like PGPASSWORD or sshpass look identical to standard command syntax, leading tools like Gitleaks and TruffleHog to miss 215 of the vulnerable files during testing.

Are files stored only on local developer machines safe from exposure?

Local files remain vulnerable even if they are never pushed to GitHub. The unencrypted JSON files can be bundled accidentally into Docker containers, npm packages, or synchronised backups, whilst developer-targeting malware and infostealers routinely scan workstations to extract credentials stored in plain text.

Sources and Methodology

This dispatch is based solely on reporting published by The Hacker News on 7 November 2026 (Claude Code's “Don't Ask Again” File Exposes Passwords and Keys in 1,122 Public Copies on GitHub), covering research from Apiiro. ROCKSTARmedia Infosec has not independently verified, inspected, or tested the external repositories, underlying code, or vendor communications cited in the source material.