Claude Code Flaw Leaked Secrets in 1,122 GitHub Repos

A security research team has found that Claude Code, Anthropic's AI coding assistant, exposed credentials in 1,122 public GitHub repositories through its "Don't Ask Again" permission setting. The finding was reported by Apiiro and surfaced on Hacker News, where the discussion drew more than 200 points and over 170 comments.

What the research found

Claude Code offers developers a convenience feature that lets them approve a file-write or command action once, then tell the assistant not to ask for permission again for similar actions within that session or project. According to the report, this setting, combined with how coding agents handle configuration files and environment variables, resulted in sensitive values such as API keys and passwords being written directly into files that were later pushed to public GitHub repositories.

The number cited, 1,122 public files, refers to repositories where this exposure pattern was identified during the research. It is not yet clear how many distinct organizations or individual developers were affected, nor whether Anthropic has issued a specific statement or patch in response to this particular report.

Why this matters now

AI coding assistants have moved quickly from experimental tools to part of daily development workflows, and permission fatigue is a known trade-off of that speed. A "don't ask again" style setting exists because constant confirmation prompts slow developers down. The same setting, though, removes a checkpoint where a human might otherwise have noticed a secret about to be written into a tracked file.

This is not a new category of mistake. Hardcoded credentials in public repositories have been a recurring problem since long before AI assistants existed. What changes here is the speed and scale: an agent that writes code autonomously across many files in a single session can repeat the same mistake across dozens of commits without anyone reviewing each change line by line.

Who is actually affected, and how

Two groups are worth separating here. Individual developers and small teams, including freelancers and startups building quickly with AI coding tools, are often the ones most likely to grant broad "don't ask again" permissions, mainly because they are working solo and want fewer interruptions. For this group, a single leaked key in a public repo can expose a database, a payment provider account, or a third-party API quota to anyone who finds the commit history.

Larger engineering organizations face a different version of the same risk. Even where repositories stay private, internal tooling often mirrors code to shared platforms, and a secret written by an AI agent can pass through code review unnoticed if reviewers assume AI-generated code follows the same conventions as human-written code around secrets management. Private repositories are not immune either; a misconfigured access control or an accidental shift to public visibility carries the same consequence.

It is not yet clear from the source whether the 1,122 files were found exclusively through Claude Code, or whether similar patterns exist across other AI coding agents offering comparable "remember this choice" settings. The report's focus is on Claude Code, and claims about other tools should be treated as unconfirmed until independently verified.

What teams can do now, without overreacting

The sensible response is to treat an AI assistant's write permissions the way teams already treat CI/CD pipeline permissions: scoped, logged, and reviewed on a schedule, rather than abandoning the tools altogether. Teams using Claude Code or similar assistants can reasonably revisit any "don't ask again" approvals granted for file writes involving configuration files, environment files, or anything resembling credentials, and reset those permissions to default.

Running a secret-scanning tool against existing repositories, both public and private, is a practical first step, since many scanning tools detect common credential patterns retroactively rather than only at commit time. Teams that haven't done this should also check whether any exposed keys turned up are still active. Rotating a credential only helps if it happens promptly after discovery, not weeks later during a routine audit.

What isn't yet justified is treating this as proof that AI coding agents are inherently less careful with secrets than human developers. Developers have leaked credentials to public repositories for years without any AI involved; the mechanism here is an agent acting on a permission a person granted, not an agent independently deciding to expose data. That distinction shapes how organizations should design review processes going forward: the fix lives in permission design and repository hygiene, not in avoiding AI coding tools altogether. Organizations building or maintaining custom software, including through software consulting engagements, may want to add a review of AI coding agent permissions as a standard item in security audits, alongside existing checks on dependency vulnerabilities and access control. Teams that rely on outside developers for ongoing work, whether through staff augmentation or IT outsourcing arrangements, should also confirm that permission policies for AI assistants are written into the engagement from day one rather than left to individual developer habits.

What would make this issue worse, or better

A few developments will clarify how serious this turns out to be. Whether Anthropic responds publicly with a statement or changes the default setting for Claude Code is one signal worth tracking. Whether similar reports surface for other AI coding assistants with comparable permission models is another, since that would point to a pattern across the category rather than an issue specific to one product.

It's also worth watching whether GitHub or other hosting platforms introduce detection mechanisms aimed specifically at AI-agent-introduced secrets, separate from the general secret-scanning features that already exist. Until then, the most reliable defense is scanning repositories directly and keeping a tight rein on what permissions coding agents are granted by default. Teams evaluating new AI-assisted development workflows, including through our own AI solutions work, tend to find that the permission model matters as much as the model's coding ability.

If your team is weighing how to bring AI coding assistants into an existing workflow without inheriting risks like this one, it helps to talk through the setup with people who build and audit these systems regularly. You can reach out through our contact page to discuss where your current review process might need adjusting.