Claude Code Permissions Can Leak Secrets and Switch Off Your Checks

Everyone who has used Claude Code, Anthropic's coding agent, has seen the prompt. It asks before running a shell command, and one of the answers is "Yes, and don't ask again."

Apiiro, a software security company, went looking for what that answer leaves behind. It found 104,185 public copies of the settings file where those approvals land, and 1,122 of them held at least one password, token or key.^[1]

The usual reading is that people committed a file they shouldn't have. That's true, and it misses the larger point. Every approval, plugin install and mode switch is a write to your coding agent's own settings, and those settings decide two things: what leaks, and which of your checks still run.

What does "don't ask again" actually save?

It saves an allow rule in a settings file inside the project, so matching commands run without asking in later sessions. Sometimes the rule is a pattern, such as npm test *. Sometimes it's the exact command, and then any password typed into that command is saved too, in plain text.^[1]

Claude Code tries to keep that file out of git. The first time it writes the file, it adds it to the user's global git excludes, a setting that lives on one person's computer.^[2] That protection doesn't travel with the project, and it does nothing for a copy someone already committed.^[1]

The numbers from Apiiro's write-up, as reported by The Hacker News:^[1]

• In 539 of 1,105 traced repositories, a commit listing Claude as a co-author changed the file.
• Counting older versions, the shared project file and saved chat logs, the total is 2,539 secrets across 1,994 repositories.
• Of 16 coding agents compared, Claude Code is the only one confirmed to save the full approved command in a project file by default.

Apiiro didn't test whether the secrets still work. One company it notified confirmed its key had been live.

Where are Claude Code permissions stored?

Claude Code reads permissions from settings files at several levels: your own user file, a shared project file teams commit on purpose, a project-local file meant to stay on one machine, and managed settings an administrator sets for the organization. "Don't ask again" approvals land in the project-local file.^[2]

That layout is sensible, and it's also four places your agent's behavior is configured. Most teams review the shared file in pull requests. Almost nobody reads the local one, because nobody wrote it by hand.

What does the Claude Code team say?

The Claude Code team answered the same day on Hacker News. The reply makes three points, each of them good advice, and adds that the team is looking into what it can do to prevent this.

Auto mode hands approvals to a classifier instead of a hand-kept list, and we've looked at what auto mode actually reviews. All three answers treat the settings file as the user's problem to keep tidy.

Goldman Sachs reached for a different answer. Internal guidance updated in October restricts Claude Code and GitHub's coding tools to the bank's engineers, after a review of productivity and risk.^[4]

Narrowing who runs the agent is a reasonable call for a bank, and it doesn't change what the agent writes. The leaked files in Apiiro's study sat in software repositories, where engineers already work.

Can a plugin change your agent's settings without asking?

Yes, and Postman's desktop app did it to two coding agents. In an October 25 GitHub issue, a Postman user showed that the Postman desktop app had installed its own plugin into Claude Code and Codex, OpenAI's coding agent, and recorded its startup hook as trusted in Codex's config.^[5]

The hook told the agent to route API work through Postman. The reporter called automatically changing unrelated coding agents and approving your own hook "a severe consent and trust-boundary problem." Postman reverted the change on November 5 and said it would redesign the experience "with the right level of control."^[5]

This is about to get bigger. DeepSeek says about 35,000 third-party plugins already run on its Harness agent app, roughly 60% of active users have created or installed one, and an official marketplace is coming.^[6] Plugins and saved approvals are now a large part of what a coding agent is.

Can a routine operation switch off a policy check?

In a controlled study, yes. Four researchers at CSIRO, Adelaide University and UNSW installed policy and approval plugins in five released agent harnesses, the software that wraps a model with tools and permissions. They then ran ordinary operations those harnesses support, and in two cases a prohibited edit ran while every plugin reported healthy.^[7]

The mode switch. On developer previews of DeepSeek Harness, switching the policy plugin from observe to enforce mode, a documented step, moved it behind the approval plugin in the queue of checks. From then on it saw no edits. Five live models made 28 reads and 28 edits, and the policy evaluated every read and none of the edits.^[7]

The saved approval. The second case is the same click Apiiro studied, measured from the other side. On OpenCode, an open-source coding agent, one "always" reply saved an allow rule, and the next prohibited edit ran without a policy review.

The reviewer plugin only looks at requests that still need approval, and that edit no longer did. Two control runs that answered "once" had every later edit reviewed.^[7]

A permanent approval changes which later checks happen. That's why approval is architecture, not vigilance: the click you make once decides what gets looked at from then on.

Why didn't the tests catch it?

Because the tests checked the work, not the path it took. The researchers asked live models to build a feature across the mode switch, with all 390 of the project's existing tests required to pass.

The work passed with the policy in the path and with it out, and the policy saw none of the 19 covered attempts in the broken arrangement.^[7]

A green test suite and a healthy plugin list told the team nothing about whether the check ran. Only joining each edit to its policy record exposed the gap, which is the same lesson as evidence from outside the agent.

The Claude Code case went the other way: Anthropic's hook plugin kept checking after a saved allow rule.^[7]

What the study can't tell us

The authors chose their cases to show that these failures happen, not how often. The main harness was a developer preview, the operator replies were programmed, and only one Claude Code plugin was tested, and it held. We read it as a direction: approvals and plugins are stored state, and stored state can remove a check without anyone seeing.

How do you check your coding agent's permissions this week?

Treat your agent's settings the way you treat any other configuration: read what got written, and test that the checks still run after the operations you actually use. Seven checks:

1. Open the shared and local settings files in every project, and delete any rule that holds a secret.
2. Rotate anything that ever appeared in them, including in git history, before you clean up.
3. Add the local file to each project's own ignore list, not only your machine's.
4. Approve patterns or variables, never literal commands with a secret inside them.
5. Turn on secret scanning wherever your code is hosted.
6. List the plugins and hooks each agent loads, and remove any nobody installed on purpose.
7. After a mode change, a plugin install or a permanent approval, try one prohibited action on purpose and confirm it gets stopped.

The trust boundary is designed, not assumed, and these settings files sit inside it. Whether you commit the local file or not, it is part of how your software gets built.