Claude Code Security Flaw Exposes 1,122 Passwords and API Keys on Public GitHub Repositories

Claude Code's "Don't Ask Again" Feature Creates Major Security Vulnerability

Anthropic's popular AI coding assistant Claude Code has inadvertently exposed 1,122 sensitive credentials on public GitHub repositories, according to security researchers at Apiiro1

1

. The security vulnerability stems from how the tool handles its "Yes, and don't ask again" permission option, which was designed to streamline developer workflows but ended up storing complete shell commands, including embedded passwords and API keys, in local settings files2

2

.

When users approve Claude Code to execute automated shell commands without repeated prompts, the entire command gets stored in a file called .claude/settings.local.json on the user's computer3

3

. The problem arises because these commands often contain database passwords, cloud service keys, and other sensitive credentials needed to connect to databases or call external software services. Rather than storing just a permission record, Claude Code saves the full command with all embedded secrets intact1

1

.

Over 100,000 Exposed Settings Files Discovered on GitHub

Apiiro security research team members Shmulik Cohen and Matan Giladi examined 104,185 publicly accessible copies of the local Claude Code settings file across 103,617 GitHub repositories2

2

. Their investigation revealed that approximately 1.1% of these files contained real secrets, totaling 1,379 distinct credentials. A broader investigation that included historical file versions and other AI coding tool records uncovered 2,539 distinct credentials across 1,994 public repositories3

3

.

The exposed sensitive credentials belonged to 63 different organizations, ranging from small development teams and startups to established technology vendors1

1

. Among the discoveries were production database passwords, a cloud management API key from a database provider, and credentials associated with an application handling medical records2

2

. While Apiiro did not attempt to test these credentials or access affected systems, one organization confirmed that an exposed key had been active3

3

.

Why Anthropic's .gitignore Protection Failed

Anthropic's documentation states that the .claude/settings.local.json file gets added to a developer's global .gitignore list, which should prevent it from being shared publicly1

1

. However, this safeguard doesn't cover every scenario. The .gitignore setting isn't reflected at the repository level, meaning the local settings file can be uploaded accidentally if a repo is cloned to another machine or a folder becomes a repo later1

1

.

In many cases, Claude Code itself commits changes to the settings file without user input, compounding the automation risks1

1

. The protection also fails when files are already being tracked by Git or when projects are moved or configured differently3

3

. Even after these files are discovered and removed from a repository, the passwords and API keys can persist in forks of the original project if developers aren't careful1

1

.

Long-Standing Issue Finally Gets Attention

This security vulnerability was first flagged in a Claude Code bug report as far back as August of 20251

1

. Other bug reports noted that the sensitive settings file was sometimes not added to the user's .gitignore list or that Claude Code could add sensitive commands to another file not protected from git sharing. All these bug reports were closed without action after 60 days of inactivity1

1

.

Boris Cherny, Anthropic's head of Claude Code, responded in a November 7 Hacker News discussion, saying the team is "looking into what we can do to prevent this"1

1

. He noted that these settings files should never be checked into source control and suggested cases arose only when files were manually created and checked in. When another user pointed out that sensitive commands can still be saved to settings files in auto mode, Cherny acknowledged it as a "good catch" and said the team is thinking through improvements1

1

.

Secret Scanners Miss 215 Exposed Credentials

Cherny recommended that Claude Code users employ secret scanners, tools that can trawl files for sensitive information and scrub it out1

1

. He indicated the team was considering building this kind of secret scanning capability directly into Claude Code. However, Apiiro researchers discovered that 215 of the roughly 1,100 public secrets found in Claude Code settings files were not flagged by two popular secret scanners, gitleaks and TruffleHog1

1

.

This gap in detection highlights the limitations of current security tools when dealing with AI agent safety issues. The improper handling of credentials by AI coding assistants creates new attack surfaces that traditional security measures may not adequately address.

Broader Implications for AI Agent Security

The Claude Code incident raises concerns about growing corporate reliance on AI agents that can operate software and access sensitive systems. According to VentureBeat's October 2026 VB Pulse research survey on Agentic Security and Identity, 24% of 101 enterprise AI and security leaders reported their agents mostly operate using shared API keys or credentials associated with people or service accounts2

2

. Another 20% had no automated way to detect when an AI agent takes an unauthorized action2

2

.

The security risks extend beyond what an AI agent might do while running. The records it leaves behind can expose valuable information long after a task finishes2

2

. This isn't the only case of an AI agent unintentionally leaking sensitive information. Last month, Meta suspended the sharing feature on its Muse agent after security researchers found the URLs for those links could be easily guessed1

1

.

What Organizations Should Do Now

Apiiro recommends that organizations search public GitHub repositories for .claude/settings.local.json and .claude/settings.json files, review Git history for deleted copies, and rotate every credential these files may have contained3

3

. Developers should reference database credentials through environment variables, such as $DB_URL, rather than placing secrets directly in commands3

3

.

Removing an exposed settings file from GitHub may not be sufficient, since previous versions can remain accessible through the repository's history or copies made by other developers2

2

. Organizations need to assume that once credentials appear in public repositories, they may have been compromised and should be rotated immediately.