Developing: Claude Code Settings Files Expose Passwords and Keys on GitHub

Claude Code users have exposed passwords and API keys in public GitHub settings files, Ars Technica reported, after a routine permission choice saved commands containing those secrets. ^[1]

Security firm Apiiro found 1,122 public copies of the tool's local settings file containing at least one secret, according to figures reported by The Hacker News. Those files held 1,379 distinct secrets and were associated with 63 organizations. ^[1][4]

The risk starts with an ordinary convenience: letting a coding assistant run a command again without asking permission. If that command contains a password or access token, Claude Code can preserve the secret in its permission rules. Publishing the resulting file can hand the credential to anyone who reads the repository. ^[1][3][4]

Anthropic says it is looking at ways to prevent the problem. Boris Cherny, a member of its Claude Code team, said the file is intended to stay out of source control and pointed to the tool's existing protection against accidental publication. ^[2]

The choice at the center of the exposure is "Yes, and don't ask again". For an eligible shell command, selecting it can save a lasting permission rule in .claude/settings.local.json, including the exact command and any secret typed into it. ^[1][3][4]

How permission becomes exposure

Claude Code is Anthropic's coding assistant. It asks users to approve many shell commands, instructions that run programs or perform tasks on their machines. A lasting approval lets a permitted action run again without another interruption. Anthropic documents the local settings file as one place those approvals can be saved. ^[3]

A password inside a command creates the trap. The user is approving an action, but the saved rule may also retain the credential used to perform it. The permission prompt itself does not publish anything. Exposure happens later if the settings file is committed or copied into a public repository. ^[1][4]

Apiiro's scan reportedly found database passwords, SSH credentials for logging into remote servers, tokens for software-hosting and package services, and access keys for Amazon Web Services accounts. A working credential can let another person act with whatever access it grants, making the file more than an embarrassing record of past commands. ^[4]

Anthropic's documentation says Claude Code adds the local file to the user's global Git excludes when it creates the file inside a repository. That tells Git, the software used to track code changes, to leave the file out of new changes on that user's setup. ^[5]

But the protection belongs to the user's Git configuration. It does not travel with the project. A file created by hand, a copy moved to another machine or a file already tracked by Git can escape it. Anthropic's documentation specifically says a manually created local settings file should be added to the project's .gitignore, the project's own exclusion list. ^[1][4][5]

That leaves a security boundary dependent on how a file was created and where it goes next. The word "local" in its name is a description of its intended use, not a guarantee that it stays private.

What the scan found

Apiiro examined 104,185 public copies of the local settings file across 103,617 repositories, according to The Hacker News. About one in 93 copies contained at least one secret, calculated from the firm's reported figures. ^[4]

The number of distinct affected users, credentials that still work and credentials used by outsiders is not established. Apiiro said it did not test whether the credentials remained usable, according to The Hacker News, which separately reported that one notified organization confirmed a key had been live. That confirmation does not establish an active share of the wider collection. ^[4]

Cherny recommended secret scanning, which searches files for material that resembles credentials. He gave no release date or committed fix for this exposure. ^[2]

Scanning is useful, but Apiiro's reported tests show why it cannot be the entire response. Two popular tools, gitleaks and TruffleHog, did not flag 215 of the roughly 1,100 files containing secrets. That result does not mean the tools detect nothing. It means some secret-bearing files in this sample passed without a warning. ^[1][4]

The issue also has a longer history than the public scan. According to The Hacker News, a bug report about approved commands being saved word for word was filed in August 2025 and later closed by an automated bot after inactivity. That history does not establish that Anthropic had confirmed this specific public exposure then. ^[4]

What to check today

The immediate check is concrete: look for .claude/settings.local.json and .claude/settings.json in current repositories and in Git history. Apiiro recommends checking both files, rotating credentials found in them, removing tracked copies and adding the local file to the repository's .gitignore. ^[4]

Rotation means replacing the exposed credential and revoking the old one. Deleting a password from a file does not change the password, and deleting an access key from the latest version does not withdraw the access it grants. The credential itself needs to be dealt with. ^[4]

History matters because Git retains earlier versions. Forks, separate copies of a repository, can also preserve a file after its removal from the original project. Ars reported that exposed files can persist in those forks. Checks therefore need to extend beyond the current view of a project's files. ^[1][4]

For Anthropic, the next decision is what Claude Code should retain when a user grants lasting permission. Cherny said the team was looking at prevention. ^[2]