Can Claude Code's "Don't Ask Again" Option Leak Your Passwords?
機械翻訳 / Machine-translated
A
AI Friends
2時間前・14分で読める
機械翻訳 / Machine-translated
@aifriends
AI Friends（https://aifriends.jp）のクロスポスト公式アカウント。AIツールの紹介・使い方・できることを、中学生でもわかるやさしい日本語で届けます。
Have you ever clicked "Yes, and don't ask again" in Claude Code? It turns out that this seemingly convenient shortcut can inadvertently publish your passwords to GitHub. This article explains what happened and what you can do about it today.
Security firm Apiiro published its findings on November 5, 2026. As reported by GIGAZINE, a total of 2,539 secrets — passwords, API keys, and other sensitive information that should never be shared — were found on GitHub.
The focus of the investigation was .claude/settings.local.json, a configuration file created by Claude Code. There were 104,185 publicly accessible files with that name.
Of those, 1,122 files contained secrets, spanning 63 organizations.
Reports indicate that the exposed data included administrator passwords for medical records databases and production credentials for payment services.
Before executing a command, Claude Code asks, "Is it okay to run this?" If you select "Yes, and don't ask again," that command is recorded in the configuration file.
The problem is that the command string is saved verbatim. If you've written a password directly into a database connection command, that password gets saved right along with it.
This configuration file is meant to stay on your own machine. However, if you accidentally add it to Git — the system used to track changes to source code — it gets published to GitHub.
Git's exclusion settings (.gitignore) are stored per machine; they won't apply on a different computer. Worse, once a file has been committed to Git, adding an exclusion rule won't protect it.
Here's a breakdown of the secrets that were found:
Larger files posed a greater risk. Configuration files over 8 KB contained secrets 9.9% of the time — the more you use the tool, the more "don't ask again" entries accumulate.
Another concern is the limits of detection tools. Using two commonly used tools, 215 of the 1,122 files containing secrets went undetected by both.
Passwords get recorded as "just part of a command." Tools designed to find keys in a known format tend to miss them.
In fact, a similar problem was flagged in the spring. TechTalks reported in April 2026 on research by security firm Lakera.
Of roughly 46,500 npm packages (npm being the service that distributes JavaScript components) examined, 428 contained the same configuration file. Thirty of those packages — across 33 files — contained usable credentials.
The latest research takes place on GitHub and is far larger in scale. The venue is different, but the root cause is the same: commands being saved in their entirety.
Boris Cherny, the lead developer of Claude Code, commented on Hacker News on November 7, 2026.
According to Cherny, when Claude Code creates this file, it includes a mechanism to exclude it from Git. His interpretation is that the leaked files were therefore created manually and added to Git by hand.
At the same time, he acknowledged that Claude Code has not, until now, performed any sanitization of secrets. He noted that adding a mechanism to detect credentials and preventing secrets from being saved in automated mode are both under consideration.
The discussion also included pushback: "An allowlist has predictable outcomes, but letting an AI audit its own behavior introduces uncertainty." That debate remains unresolved.
There are several ways to protect yourself. Here's how they compare:
If your secrets have already been exposed, simply deleting the file is not enough. You must revoke any credentials that appeared in the public history and issue new ones.
Cherny also recommends enabling secret scanning (automatic secret detection) on GitHub and similar platforms.
The number of developers in Japan using Claude Code is growing, and this issue is not someone else's problem.
Consider a contract development firm: five team members each press "don't ask again" while running commands to connect to a client's database. If one of them accidentally commits the configuration file, the client's production environment password ends up in a public repository.
The same applies to solo developers. If a payment service key is mixed into a hobby project pushed to GitHub, it could lead to fraudulent use.
For organizations, one option is to add a rule to your CI pipeline (the system that automatically runs tests and checks) that causes a build to fail if .claude/ is found in anything being published. TechTalks recommends similar measures.
Q. Is my repository safe?
A. Check whether .claude/settings.local.json has been added to Git. It's also worth looking inside the file for any passwords or tokens.
Q. Should I stop using "Don't ask again" altogether?
A. Using it isn't inherently wrong. Just avoid it for commands that contain passwords, and move those values to environment variables instead.
Q. What should I do if I've already exposed secrets?
A. Deleting the file isn't enough. Revoke any credentials that ended up in your history and reissue them.
Q. Is secret scanning sufficient?
A. Not entirely. In this research, 215 out of 1,122 files went undetected by two commonly used tools.
Start by checking whether .claude/settings.local.json has been committed to any of your repositories.
This article is a cross-post from AI Friends.
