Ars Technica reports that Claude Code’s “do not ask again” permission prompts can save commands containing passwords and API keys into project settings files. When those files are pushed to GitHub, the secrets in them become visible to anyone who can see the repository.
The problem in brief
Claude Code is Anthropic’s AI coding assistant. It runs in a developer’s terminal and can read files, edit code and run shell commands. Before it runs a command that could have side effects, it normally asks the user for permission. The user can approve the command once, or tell the tool not to ask again for that command or for commands like it.
When the user picks “do not ask again”, Claude Code saves a permission rule to a settings file inside the project, usually in a hidden folder called .claude. The rule is plain text and often records the command much as it was written. If that command had a credential in it, the credential is saved too. Examples include an API token passed in a request header, a database password on the command line, or a cloud access key set as an inline variable.
Ars Technica reports that settings files like this have turned up in public GitHub repositories with passwords, API keys and other sensitive values in them. The exposure is accidental. Nobody meant to publish the secrets. They were saved as a side effect of a convenience feature and then committed with the rest of the project.
Where it came from
Secrets leaking through version control is an old problem. Developers have committed environment files, configuration files, private keys and hard-coded tokens to public repositories for years. Attackers scan public code hosting sites for exposed credentials, and tools exist on both the defensive and offensive side to do this automatically.
AI coding agents add a new way for this to happen. A traditional configuration file is something a developer writes on purpose, so they have at least some chance of noticing a password in it. A permission rule is written by the tool as a by-product of clicking through a prompt, often in the middle of a task. Many users will not think of that click as saving data to disk. Fewer still will think of it as saving data into a folder that might be committed to a shared repository.
How large the exposure is has not been independently checked here. It is also not known how many of the exposed credentials were still valid, or whether any of them have been misused.
How it works today
Claude Code reads settings from more than one place. Settings can apply to one user across all projects, to a project shared with collaborators, or to a project on one machine only. The project-level files live in the .claude directory at the root of the repository. One project file is meant to be shared and committed. A separate local file is meant to stay on the developer’s own machine.
Saved permission rules generally go in the local file, which is intended to be left out of version control. Leaks can still happen in several ways. The file may not be listed in the project’s .gitignore. A developer may add it to a commit with a broad command that stages everything. Someone may copy rules into the shared file. Or a whole project folder may be uploaded without checking what is in it. The source does not say exactly which of these paths account for the reported cases.
Once a secret reaches a public repository, deleting the file in a later commit does not remove it. The value stays in the repository’s history, and it may already have been copied by automated scanners or by anyone who cloned or forked the project. The usual advice is to treat any exposed credential as compromised and to revoke or rotate it at the provider. Cleaning up the repository comes after that.
Common misconceptions
“The AI model leaked my secret.” In the scenario described, the model does not decide to publish anything. The credential is written to a local file by the tool’s permission system and is then published by the normal Git workflow. The weakness lies in how persistent settings are stored and handled, not in what the model generates.
“Local settings files are never committed.” Some files are designed to be ignored by Git, but that depends on the project’s ignore rules and on how the developer stages changes. A file that is meant to stay local is not guaranteed to.
“Deleting the file fixes it.” As above, Git keeps history. Removing a file in a new commit leaves earlier commits untouched. Rotating the credential is the step that actually removes the risk.
“Private repositories are safe.” Private repositories limit who can see the secret, but they do not remove it. Collaborators, integrations, backups, and any later decision to make the repository public all extend its reach.
“This only affects one product.” The report concerns Claude Code. However, any tool that saves approved commands, shell history or session state into a project directory can create the same kind of risk.
Where to look next
Readers who use Claude Code should look in the .claude directory of each project they have pushed to a remote. They should check whether any settings files are tracked by Git and search them for tokens, keys and passwords. Anthropic’s Claude Code documentation describes the settings hierarchy and which files are meant to be shared.
GitHub’s documentation on secret scanning and push protection explains how the platform detects some known credential formats and can block them before they are pushed. Open-source scanners can also check a repository’s full history. Guidance from bodies such as OWASP covers secrets management more broadly, including keeping credentials in environment variables or a dedicated secrets manager instead of typing them into commands. Ars Technica’s original report has the specific findings behind this article.
Frequently asked questions
Does Claude Code save my approved commands to a file?
Yes. When you choose not to be asked again about a command, Claude Code records a permission rule in a settings file so it can run similar commands later without prompting you. These files are typically stored in a .claude folder inside the project. If the approved command included a password or API key, that value can be saved in the rule as plain text.
How do secrets from Claude Code end up on GitHub?
According to Ars Technica’s reporting, settings files containing saved permission rules have been committed to repositories and pushed to GitHub. This can happen if the local settings file is not excluded by the project’s ignore rules, if it is staged with a broad commit command, or if rules are copied into a shared settings file. Once pushed to a public repository, anyone can read the secrets.
What should I do if I find a secret in my Claude Code settings?
Treat the credential as compromised and revoke or rotate it with the service that issued it, such as a cloud provider or API vendor. Then remove the value from the settings file and make sure the file is excluded from version control. If it was already committed, the secret remains in Git history, so rotation matters more than deleting the file.
Is settings.local.json ignored by Git automatically?
The local settings file is intended to stay on the developer’s machine and not be shared. Whether Git actually ignores it depends on the project’s .gitignore configuration and on how the developer stages changes. Developers should not assume it is excluded. Running a status check, or listing tracked files in the .claude directory, will show whether it is being committed.
How can I stop AI coding tools leaking credentials?
Avoid typing secrets directly into commands. Store them in environment variables or a secrets manager and refer to them by name. Make sure tool-specific settings folders are covered by ignore rules, review staged changes before committing, and enable secret scanning or push protection on your repositories. These habits help with any tool that records commands or session data, not only Claude Code.
Sources and further reading
- Ars Technica: the original report on Claude Code settings files exposing secrets on GitHub
- Anthropic: Claude Code documentation on settings files, scopes and permission rules
- GitHub: documentation on secret scanning, push protection and removing sensitive data from repository history
- OWASP: general guidance on secrets management in software development
Surfaced from the rss:arstechnica signal “AI tool credential exposure”. AI-assisted draft, editorially reviewed.
