The security researchers did not have to break anything. They searched, and the results came back in the thousands. On Monday, the firm Apiiro disclosed that a convenience option in Claude Code, Anthropic’s coding agent, stores passwords, API keys and SSH login details in plain text in a local configuration file, and that 2,539 credentials had been exposed that way. More than a thousand copies of those files turned up in public repositories on GitHub.
The option is labeled “don’t ask again.” A developer working with the agent is interrupted each time a command needs approval, and the checkbox is how the interruptions stop. What the setting also does is write the sensitive values it has been given, in readable text, to a file on the machine, where anything running as that user can open it.
This matters because of what these tools have become. A coding agent is not a text box. It reads the file system, runs commands, installs packages and reaches network services, and it is increasingly given standing credentials so it can work without a person watching every step.
The checkbox was designed to reduce friction for a human sitting at a keyboard. The same setting removes the last checkpoint from a process that is meant to run when nobody is at the keyboard.
The friction is real, which is why the button exists. A developer who approves two hundred commands in an afternoon stops reading the prompts, and a prompt nobody reads is worse than no prompt, because it trains the habit of clicking yes. Tool makers know this. They add an option to silence the queue, and the option becomes the default within a week.
Anthropic’s response has been to acknowledge the problem rather than dispute it. The person who leads Claude Code said the issue is real and that the fix the company has in place may not fully resolve it. That is a more candid statement than most security disclosures produce, and it is also an admission that customers cannot wait for a patch to feel safe.
The word “local” is doing a lot of work in the disclosure, and it should not reassure anyone. A file on a developer’s laptop is not a breach in the ordinary sense, but it travels. It goes into backups, into cloud sync folders, into a repository when someone commits a directory they meant to ignore, and into a support bundle sent to a vendor. The line between a local file and a public one is thinner than the phrase suggests.
Secrets in repositories are an old problem, and the industry has spent a decade building tools to catch them. What changes here is the shape of the exposure. A developer who commits a key has usually touched it once. An agent that has been told not to ask again holds the key in a file and reads it on every run, and the file persists long after the task that required it has finished.
The count of 2,539 is a floor rather than a total. It is what one firm found in a scan of what was reachable, and it does not include files on machines that nobody has indexed, or copies in private repositories whose owners do not know they are exposed. A credential is also not a statistic until it is used. The question that follows every disclosure of this kind is how many of those keys were live, how many belonged to systems worth entering, and how many were already known to someone who had no business knowing them.
The remedy is boring and not fully in the vendor’s hands. Every credential that passed through an affected file should be treated as compromised and rotated, not audited and left in place. Repositories should be scanned for history as well as for the current commit, because deleting a file does not remove it from the record. Tokens should be scoped to the narrowest permission that lets the job run, and should expire, so that a leaked value is worth less by the time it reaches anyone.
There is a division of blame that both sides will argue about, and neither answer is complete. A user who pastes a production password into a tool that writes it to disk has made a mistake. A product that offers a one-click way to store that password in the clear has designed the mistake into the workflow, and design failures scale in a way that individual errors do not.
What to watch is whether a fix ships that encrypts or removes the values already written, whether the company publishes how many of the exposed keys were active, and whether the repositories that carry the copies are notified. A disclosure that stops at a number and a patch note leaves the affected developers to find out on their own.
The checkbox is still there. It is a small piece of interface, drawn to look like a courtesy, and it is now the part of the product that security teams will ask about first.
