OTWopentechwire
Tech Intelligence, Openly Wired
Dev

Thousands of Credentials Left Exposed by Claude Code Configuration Flaw

A design oversight in how Anthropic's coding assistant stores user preferences has led to the accidental publication of database passwords, API keys and root credentials across public repositories.

AS
Arjun S. Mehta
AI Correspondent · Bengaluru
Nov 12, 2026
6 min read
Thousands of Credentials Left Exposed by Claude Code Configuration Flaw
Credit: Aurich Lawson

A Security Gap in Plain Sight

Over 100,000 instances of a single configuration file from Anthropic's Claude Code have appeared in public GitHub repositories, and roughly 1,100 of them contain live credentials. Security researchers at Apiiro discovered the exposure in early November 2026, tracing the problem to how Claude Code records user decisions about automated shell commands. The affected files include database passwords, API tokens for third-party services, and private SSH keys, all stored in plaintext within a JSON configuration file that developers never intended to share.

The scope spans 63 organisations, from individual contractors to mid-sized software teams. While the absolute number of files containing secrets represents about one per cent of all uploaded Claude Code settings, the exposure is broad enough that attackers scanning GitHub for these specific filenames can harvest working credentials with minimal effort. Forks of affected repositories compound the problem, because removing a file from the original project does not automatically purge it from derivative copies.

How the Exposure Happens

Claude Code, like other AI-assisted development environments, frequently suggests shell commands to automate tasks such as database migrations, environment setup or deployment scripts. When a user approves a command and selects the option labelled "Yes, and don't ask again," the tool writes that approval as a rule into a local file named ".claude/settings.local.json" on the developer's machine. The rule can take the form of a pattern, but in many cases the tool stores the complete command verbatim, including any credentials embedded in connection strings or environment variables.

Anthropic's documentation states that this settings file is added to a global .gitignore list during installation, which should prevent version-control systems from tracking it. The global ignore list, however, applies only to the machine on which Claude Code was first configured. If a developer clones the repository to a different workstation or converts an existing directory into a Git repository after the fact, the local .gitignore may not include the Claude Code entry. At that point, the settings file becomes eligible for commit.

Apiiro's analysis found that in a significant number of cases, Claude Code itself initiates commits that include changes to the settings file, without prompting the user to review the staged files. This behaviour increases the likelihood that credentials will reach a public repository before the developer realises the file has been added to version control.

The Credential Landscape

The researchers catalogued the types of secrets appearing in the exposed files. Database connection strings accounted for the largest share, often containing usernames, passwords and hostnames for PostgreSQL, MySQL and MongoDB instances. API tokens for cloud infrastructure providers, payment gateways and communication platforms also featured prominently. A smaller but more sensitive subset included private SSH keys and root login credentials for virtual machines.

Because the settings file is JSON and stores commands as strings, the credentials appear in plaintext with no obfuscation. An attacker who downloads one of these files can extract working credentials in seconds using basic text-processing tools. The researchers emphasised that the exposure is not the result of a vulnerability in Claude Code's code execution environment; rather, it stems from a mismatch between the tool's default file-handling behaviour and the realities of multi-machine development workflows.

Regional Implications for Development Teams

The discovery carries particular weight in Asia's fast-growing software sector, where remote and distributed teams are common. Developers in cities such as Bengaluru, Singapore, Hanoi and Manila frequently work across multiple machines, including shared cloud-based development environments and on-premise workstations. The reliance on global .gitignore entries creates a gap when team members set up repositories on fresh machines or use containerised development environments that do not inherit global Git configuration.

Startups and scale-ups in the region often adopt new AI coding tools quickly, prioritising speed and developer experience over exhaustive security audits. That enthusiasm can lead to widespread deployment before internal security teams have reviewed the tool's file-handling behaviour or established organisational policies around configuration files. The Claude Code exposure highlights a broader challenge: as AI coding assistants become standard infrastructure, their default behaviours must account for the diversity of real-world development setups, not just the ideal single-machine scenario.

Anthropic's Design Trade-Off

Anthropic designed the "don't ask again" feature to reduce friction for developers who repeatedly run similar commands. Storing the approval locally allows Claude Code to proceed without interrupting the user's workflow. The decision to use a local settings file rather than an in-memory store or encrypted vault reflects a trade-off between convenience and security. A purely in-memory approach would require users to re-authorise commands after every restart, while encrypted storage would add complexity to the tool's setup and cross-platform compatibility.

The global .gitignore mechanism represents an attempt to bridge that trade-off, assuming that most developers will use a single primary machine or will carry their global Git configuration across environments. In practice, developers often work on laptops, desktops, virtual machines and cloud IDEs in parallel, and global configuration does not always propagate. The result is a design that works as intended in narrow circumstances but breaks down when confronted with the heterogeneity of professional software development.

Mitigation Steps and Ongoing Risk

Apiiro recommends that developers who use Claude Code immediately check their repositories for the presence of ".claude/settings.local.json" and remove it from version history if found. Because Git retains files in commit history even after deletion, a complete clean-up requires rewriting history or using tools such as BFG Repo-Cleaner. Any credentials discovered in the settings file should be rotated immediately, as there is no way to determine whether an attacker has already harvested them.

For organisations, the incident underscores the need for automated secret-scanning pipelines that run before code is pushed to shared repositories. Several commercial and open-source tools can detect common credential patterns in staged files and block commits that contain them. GitHub itself offers secret scanning for public repositories, but the feature must be explicitly enabled for private repositories under an organisation's security settings.

Anthropic has not announced changes to Claude Code's file-handling behaviour, though the company's documentation now includes a warning about the risk of committing the settings file. A more robust long-term solution would involve adding the .gitignore entry at the repository level when Claude Code detects that a directory is under version control, or encrypting the settings file by default and requiring explicit user action to export rules in plaintext.

The Broader Pattern in AI Tooling

The Claude Code exposure fits a pattern seen across the AI-assisted development landscape. Tools that aim to accelerate workflows often introduce new classes of operational risk, particularly when they generate or store artefacts that were previously created manually. Developers who write connection strings by hand are unlikely to commit them directly to version control, but an AI tool that automates environment setup may embed those same strings in a configuration file without drawing attention to the security implication.

As coding assistants become more autonomous, the boundary between user intent and tool behaviour blurs. A developer who approves a command may not realise that the approval itself will be persisted in a way that could later be shared. This mismatch between mental models and actual behaviour is a recurring source of security incidents in software that tries to be helpful by reducing the number of decisions a user must make.

What Comes Next

The immediate priority for affected developers is remediation, but the incident also raises questions about how AI tool vendors should approach default security postures. Convenience and security are not always in opposition, but when they are, the default should favour the option that fails safely. A settings file that is never committed may inconvenience users who want to share configurations across machines, but a settings file that leaks credentials can compromise entire infrastructure stacks.

For enterprises evaluating AI coding assistants, the Claude Code case offers a reminder that adoption should include a security review of the tool's file system interactions, network behaviour and data persistence mechanisms. Developer tools that write files to disk, especially configuration files, warrant particular scrutiny. The industry has spent two decades teaching developers not to commit secrets to version control; tools that automate parts of the development process must not undo that discipline by introducing new pathways for accidental exposure.

Read next
Dev

Why Data Lineage Is the Missing Link in Agentic AI Security

Sofia M. Reyes · 7 min
Dev

Enterprise AI Costs Shift From Consumption Metrics to Delivery Outcomes

Arjun S. Mehta · 5 min
Dev

Anthropic's Cursor Extension Shipped Malicious Code for Half a Day

Daniel R. Whitfield · 5 min
Spot something wrong? Email corrections@opentechwire.com. We log every correction publicly.