Apiiro finds passwords and keys exposed on GitHub through a Claude Code approval option
IA en un minuto newsroom · Editor: Jon Elgezabal
In 30 seconds
Apiiro searched GitHub and turned up passwords and access keys in 1,122 of the 104,185 public copies of the file where Claude Code records the permissions it has been granted. Claude Code leaves them there when someone approves a command for good, and they become visible if the project folder is later pushed with that file inside. Gitleaks and TruffleHog, two widely used detectors, missed 215 of those files.
On November 5, the cybersecurity firm Apiiro released a study on the permissions stored by Claude Code, Anthropic's programming assistant. It reviewed 104,185 public copies on GitHub of the .claude/settings.local.json file and, in 1,122 of them, found what it calls real secrets: passwords, API keys and other access data.
The problem starts in everyday work. Before running a terminal command, Claude Code asks for permission, and one of the possible answers is "Yes, and don't ask again". If a developer picks it, the tool keeps that exact command as an allowed rule in the project's local file, and if the command included a password, for instance to get into a database, the password is written down as is. Claude Code tries to keep the file from being uploaded: when it creates it inside a repository, it adds it to the developer's global Git exclusion list. According to Apiiro, that safeguard stays on the developer's computer instead of travelling with the project, so it does not help with a folder turned into a repository later on, a copy on a different machine or a file that had already been pushed. In 539 of the 1,105 repositories with secrets that Apiiro traced, the file changed in a commit listing Claude as co-author.
Those 1,122 files hold 1,379 distinct secrets. More than a third give direct access to a database: 122 Supabase service-role keys and 379 database passwords. There are also 43 SSH logins to public servers. Adding earlier versions of the file, the settings file that teams share on purpose and agent conversations saved in repositories, Apiiro reaches 2,539 secrets in 1,994 public repositories belonging to 63 organizations, mostly software companies.
Common tools do not catch all of them. Apiiro ran Gitleaks and TruffleHog over the 1,122 files: the first one flagged 564 and the second 643, and in 215 cases neither raised an alert. These are mostly passwords typed inside a command, which lack the recognizable format of a provider key.
Apiiro did not try any credential or connect to the servers. It calls a secret real when it is a key with the format of a known provider or a password that appears next to the address of a public server, not when it has checked that it works. It warned the affected organizations on November 2 and 3, and one of them confirmed that its key was active. The firm points out that Claude Code users have described this behavior on GitHub since August 2025 and that, by its count, Anthropic did not answer any of those reports. Its advice for anyone whose file has been published is to change the credentials first and clean up afterwards, because the history, forks and copies of the repository keep the content.
Why it matters · analysis and opinion
What stands out is that no attacker is needed: a click meant to speed up work and a file nobody checks before pushing the code are enough. Coding assistants pile up permissions over weeks, and those lists end up holding data as sensitive as the code itself. Anyone using Claude Code can open the permissions file of each project today, delete the rules that contain passwords and check that it does not appear in the repository history. If it does, the first step is to change those credentials. In the longer run, the sensible approach is for passwords to reach commands from a secrets manager rather than being typed by hand, and for security teams to include agent folders in their reviews.
Official source: Apiiro · Written with the help of AI: how we make the news
What does it mean for your business? · analysis and opinion
This affects any small business, startup, or freelance developer in Spain or Latin America that uses Claude Code on projects stored with Git, especially if the repositories are public or get cloned across several machines. Anyone who does not use this assistant, or has never clicked "Yes, and don't ask again" on a command that included a password, does not have this specific problem, although it is worth checking anyway.
The sensible move is to search for the .claude/settings.local.json file in projects and in their Git history, and check whether the approved rules contain passwords, tokens, or connection strings. If one turns up, the order matters: first change or revoke the credential, then delete the file, because old copies remain in commits, forks, and clones. After that, it is enough to stop tracking the file with git rm --cached and add it to the repository's own .gitignore, which does travel with the project. Our advice is not to rely only on an automated scanner: Gitleaks and TruffleHog missed 215 of the affected files.
Prevention costs very little, just a few minutes of review and changing some passwords. Not doing it can leave access to databases, SSH servers, or cloud services within anyone's reach. From now on, it is worth approving only narrowly scoped command patterns and using references to a secrets manager instead of writing the password inside the command.
