Meteora Web

Claude Code, settings files expose thousands of secrets on GitHub

Apiiro found over 100,000 Claude Code settings.local.json files on GitHub, about 1,100 containing secrets. Here is what to check in your repositories.

Ing. Calogero Bono 5 min read
Claude Code, settings files expose thousands of secrets on GitHub

According to security researchers at Apiiro, Claude Code is leaving secrets in public GitHub repositories. The problem starts with a local settings file that ends up online without the developer noticing. The data found includes database passwords, API tokens and root access. It matters to anyone using an AI programming assistant, because a single careless commit can expose credentials that are still valid.

A few terms before we get into the facts. .gitignore is the file that tells Git which files not to save in commits. Repository is the project folder tracked by Git. Secret means a credential, such as a password, an API token or a private key. Fork is a copy of a project made by another user on GitHub. Commit is the saving of a group of changes into the project history.

Zenithby Meteora Web The operating system for your business. Social, clients, bookings and invoices in one platform. Gyms, barbers, professionals. Discover Zenith → Free demo · no card

What was discovered about Claude Code and GitHub?

The story is reported by Ars Technica, which covers Apiiro's work. The researchers found over 100,000 cases in which Claude Code's local settings file had been uploaded to a public GitHub repository.

Not all of them contain sensitive data. Only about 1,100 files, coming from 63 different organizations, included secrets such as public API tokens, database passwords or private keys. The number is small compared to the total, but these are real credentials, not examples.

Why does the file end up online?

When the user chooses "Yes, and don't ask again" to approve a shell command, that choice becomes a rule in the local file .claude/settings.local.json. Sometimes the rule is written as a generic pattern. Often, however, the command is saved exactly as it was, with everything it contains, including any credentials.

As long as the file stays on the computer, the risk is contained, unless the machine is compromised. The trouble starts when the file enters a commit.

Shouldn't .gitignore be enough?

In theory, yes. According to Ars Technica, Anthropic's documentation indicates that this file is added to the developer's global .gitignore, which usually prevents it from being published.

The weak point is that the rule does not carry over at repository level. If the project is cloned to another machine, or if a folder becomes a repository later, the file can be uploaded by mistake. Apiiro adds that in many cases it is Claude Code itself that commits the changes to the settings, without user intervention.

The official GitHub documentation explains the difference. The .gitignore at the root of the repository, once committed, applies to anyone who clones the project. The global one in ~/.config/git/ignore applies only on your computer.

Is deleting the file enough to fix it?

No. According to Apiiro, even after the files are discovered and removed from a repository, secrets can remain in forks of the original project, if the user is not careful.

GitHub's documentation also notes that a file already tracked must first be removed from tracking with git rm --cached FILENAME, and only then does the exclusion rule take effect. Adding a line to .gitignore does not erase what is already in the history. For this reason, if a credential has ended up online, it should be treated as compromised and replaced.

Limits to know

The figures come from Apiiro's analysis, reported by Ars Technica, and we have not verified the data. We do not know how many of the credentials found were still valid, or whether third parties used them. The sources contain no response from Anthropic about possible changes to Claude Code's behavior. The picture could change if the company decided to act on how approved commands are saved.

What changes for those working in digital

If you use Claude Code, immediately check whether .claude/settings.local.json is tracked in any repository, even a private one. A private project can become public, or be cloned elsewhere. Add the file to the project's .gitignore and commit it, so the rule applies to everyone. To exclude a file only on your own clone, GitHub points to .git/info/exclude.

Then there is the habit of writing passwords inside commands. Environment variables or a secrets manager are better. In a company, it is worth adding automatic secret scanning before every push.

Our take

The case shows a design limit, not just a user distraction. A file that may contain credentials should be excluded where it matters, that is in the repository, not only in personal configuration. Leaving everything to the user works poorly, especially when the tool commits changes on its own. That said, it is also our responsibility. A command with a plaintext password is a habit to fix, with or without an AI assistant. The speed these tools promise makes discipline around secrets more urgent, not less.

Frequently asked questions

Which Claude Code file contains the secrets?

The file is .claude/settings.local.json. It stores the rules created when you approve a command with "Yes, and don't ask again". Sometimes the command is written in full, credentials included.

How many exposed files did Apiiro find?

Over 100,000 files uploaded to public GitHub repositories. About 1,100, from 63 organizations, contained secrets such as API tokens, database passwords or private keys.

Does the global .gitignore protect against the problem?

Only partly. It works on your computer, but not inside the repository. If the project is cloned elsewhere, or a folder becomes a repository later, the file can end up in a commit.

Does deleting the file from the repository remove the secrets?

No. According to Apiiro, secrets can remain in forks of the project. If a credential has been published, it should be considered compromised and replaced.

How do I exclude a file already tracked by Git?

First remove it from tracking with git rm --cached FILENAME. Then add the rule to .gitignore. Without the first step, the rule has no effect on a file already tracked.

What to watch in the coming months on Claude Code security

The key question is whether Anthropic will change how it saves approved commands. In the meantime, it is worth keeping an eye on the tool's updates.

  • Read the Claude Code release notes to see whether the handling of settings.local.json changes, starting from our article on version 2.1.319.
  • Search the history of your repositories for .claude files already committed, and rotate any credentials that appear.
  • Review your branch protection rules, using our guide to pull requests on GitHub.

Sources

Zenithby Meteora Web The operating system for your business. Social, clients, bookings and invoices in one platform. Gyms, barbers, professionals. Discover Zenith → Free demo · no card

Read next

From the blog

Latest articles