A convenience button in Anthropic’s Claude Code is now at the centre of a secrets-exposure story that reached Australian readers on November 8, 2026. Security company Apiiro reported finding 1,122 public GitHub files containing at least one secret, all tied to saved Claude Code approvals, and iTnews updated its coverage the same day. The reported trigger is the option labelled “Yes, and don’t ask again”.What the Claude Code “Don’t Ask Again” Report SaysHow the Allow Rule Lands in settings.local.jsonApiiro’s Numbers: 1,122 Files and 1,379 SecretsWhat the Reports Do Not ShowWhy Secrets End Up Inside Shell CommandsCompound commands add to the pileHow a Local File Reaches a Public RepositoryWhat Anthropic Has and Has Not SaidCompetitive Comparison: How Approval Models DifferHistorical Context: Secrets in Repositories Are an Old ProblemMarket Impact for AI Coding Tools and Their BuyersThe Australian Angle: OAIC, ASD and Essential Eight9 Fixes to Apply TodayStop the leakFind and clean up old exposureLock down the agent and the credentialsPredictions: 4 Calls for the Next 12 MonthsWhat This Means for Australian Dev TeamsFrequently Asked QuestionsWhat does “Yes, and don’t ask again” do in Claude Code?How many secrets did Apiiro find?Did Anthropic confirm or fix the problem?Were the exposed secrets used by attackers?How do I check whether my repository is affected?Is a leaked API key a notifiable data breach in Australia?Should teams stop using Claude Code?
The mechanism is simple. When a developer approves a shell command with that option, Claude Code can store it as an allow rule in .claude/settings.local.json. If the command had a database password, API key or SSH credential typed into it, the secret goes into the file as plaintext. Apiiro’s research, reported as published on November 5, 2026, found those files sitting in public repositories.
This article covers what the reports confirm, what they leave open, and what Australian teams should do this week. If you are new to the tool, our Claude Code walkthrough explains how permission prompts work before you start tightening them. One caution up front. The reporting establishes exposure through saved commands that ended up in public repositories. It does not establish that attackers used any of those credentials, and it does not show a product-wide defect.
Google · Preferred Sources
Don’t miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
Add Now
What the Claude Code “Don’t Ask Again” Report Says
Per iTnews, Apiiro scanned public GitHub and found secrets inside Claude Code settings files that should have stayed on a developer’s machine. The scan covered 103,617 public repositories. It turned up 1,122 files with at least one secret, and those files held at least 1,379 distinct secrets in total.
The quoted feature text matters, because it describes the user’s intent. Choosing “Yes, and don’t ask again” tells the tool to stop prompting for that command. It does not tell the tool to scrub the command first. Whatever the developer typed, including any credential embedded in it, becomes part of the saved rule.
You may like
Apiiro’s breakdown, as reported, named four categories. There were 379 database passwords, 43 SSH credentials, 42 version-control system tokens and 23 AWS access keys. Those four add up to 487, which leaves 892 secrets that the coverage I reviewed does not itemise.
Neither Anthropic nor Apiiro has an attributable on-record quote in the coverage I reviewed. That is why this piece paraphrases the reports and names the outlets instead of quoting executives. It also means any claim that Anthropic acknowledged, fixed or issued an advisory for this behaviour is unconfirmed as of today.
How the Allow Rule Lands in settings.local.json
Claude Code asks permission before running most shell commands. A developer can approve once, or pick the standing option. The standing option writes a Bash allow rule so the same command runs without a prompt next time. Anthropic’s documentation describes this behaviour and names .claude/settings.local.json as the file that holds it.
The documentation also frames that file as personal, local configuration, separate from project settings a team commits on purpose. That design is sensible. A developer’s private approvals should not become a team’s shared permissions. The trouble starts when the file is treated like any other file in the working tree and gets staged by a broad git add.
Here is the kind of rule that causes the problem. The example below is invented for illustration and uses placeholder values, not real credentials.
{
"permissions": {
"allow": [
"Bash(mysql -h db.internal.example -u app -p'EXAMPLE_PASSWORD' -e 'SELECT 1')"
]
}
}
A rule like that is exact. It matches one command, password included. Anything that reads the settings file reads the password too. Once the file sits in a public repository, anyone running a scanner can read it as well.
Apiiro’s Numbers: 1,122 Files and 1,379 Secrets
The table below collects every figure the verified reporting supports. I added two ratios of my own, flagged in the notes, to give the scale some context. Treat the ratios as arithmetic on the reported totals, not as findings Apiiro published.
MetricReported figureNotePublic GitHub repositories covered103,617Apiiro research, reported by iTnewsPublic files with at least one secret1,122Files, not repositoriesDistinct secrets foundAt least 1,379A floor, per the reportsDatabase passwords379Largest named categorySSH credentials43Plaintext in saved commandsVCS tokens42Can unlock source codeAWS access keys23Cloud account accessRepositories per affected file (my ratio)About 92103,617 divided by 1,122Secrets per affected file (my ratio)About 1.21,379 divided by 1,122
Database passwords dominate the named categories, at roughly 78 percent of the 487 itemised secrets. That fits the pattern. Developers often run database clients, migration tools and deploy scripts from the command line, and those tools accept passwords as arguments.
The 92-repositories-per-file ratio looks small, and it is. Roughly one affected file per 92 scanned repositories does not describe the share of Claude Code users at risk, because the 103,617 figure covers public repositories in general. Most of them probably never touched the tool. The ratio says the leak is rare in the haystack, and the secrets inside each file are still live credentials until someone rotates them.
What the Reports Do Not Show
Three claims keep circulating on social media and are not backed by the sources behind this story. I am listing them so readers can discount them.
Intentional breach. Nothing in the coverage says Anthropic exposed this data. The secrets appear in public repositories that developers pushed.Attacker access. The reports describe secrets being exposed. They do not confirm that anyone accessed a database, cloud account or server with them.A confirmed product-wide leak. The headline phrase that Claude Code “leaks developer secrets” overstates the sourcing. The supported statement is narrower. Saved commands containing secrets were committed to public repositories.
That narrower framing changes the fix. A product defect would call for a vendor patch. A workflow gap calls for repository hygiene, scanning and credential rotation, which developers control today. Anthropic may still choose to add guardrails, and that would be welcome, but nobody should wait for it.
Why Secrets End Up Inside Shell Commands
Experienced developers know they should not paste passwords into commands. They do it anyway, for good practical reasons. A quick connection test, a one-off restore, a script that needs a token for ten minutes. Shell history has absorbed this habit for decades.
An AI coding agent changes the economics. The agent proposes the command, the developer glances at it, and the standing-approval option removes friction from the next run. In that flow the developer may not even type the secret. The agent can pull it from an environment file, a config snippet or the chat itself and splice it into the command line.
The saved rule then freezes the secret in place. A shell history file stays on one machine. A settings file inside the project directory sits next to the code, which is exactly where source control tools look first.
Compound commands add to the pile
Research gathered for this article suggests Claude Code splits compound commands into separate rules for the parts that need approval. That would mean one approval could create several saved entries, and any of them could carry a credential. I could not confirm the exact splitting behaviour from a primary source, so check your own settings file rather than assuming.
How a Local File Reaches a Public Repository
The supplied reporting does not spell out the route, so this section is analysis. Three paths seem most likely, and each is a common Git mistake.
A developer runs git add . or git add -A in a repository with no ignore rule covering the .claude directory.A template or starter repository ships with the file already committed, and everyone who forks it inherits the problem.A developer pushes a personal project to GitHub without reviewing what the first commit contains.
All three are cheap to prevent. The check takes seconds, and the two commands below tell you whether your current repository is tracking the file and whether Git is ignoring it.
git ls-files .claude/settings.local.json
git check-ignore -v .claude/settings.local.json
git log --all --oneline -- .claude/settings.local.json
The first command prints the path if Git tracks the file. The second shows which ignore rule covers it, and prints nothing if none does. The third lists every commit that ever touched the file, which matters because deleting a file today does not remove it from history.
What Anthropic Has and Has Not Said
As of November 8, 2026, the supplied sources contain no on-record statement from Anthropic about the Apiiro findings. I found nothing confirming an advisory, a patch, outreach to affected users or any change to the approval prompt. Those would be reasonable next steps, but they remain unconfirmed.
You may like
Anthropic’s public documentation does lay out the controls developers can use. Permission rules come in three kinds. Deny rules block an action, ask rules force a prompt and allow rules permit it. The best-practice guidance shows a restrictive setup, with a narrow allow rule for a type-check command, a prompt before pushing code and deny rules for .env files and a secrets directory.
{
"permissions": {
"allow": ["Bash(pnpm tsc --noEmit)"],
"ask": ["Bash(git push *)"],
"deny": ["Read(./.env)", "Read(./.env.local)", "Read(./secrets/**)"]
}
}
That example comes from Anthropic’s guidance and shows the intended posture. Secrets live in files the agent cannot read, risky actions prompt, and allow rules stay narrow. The Apiiro findings describe what happens when day-to-day habits drift away from that posture.
Competitive Comparison: How Approval Models Differ
Every AI coding agent has to answer the same question. How much should a developer approve once, and for how long? The tools differ in their answers, and each answer shifts where secrets can pool. The table compares the common design patterns rather than naming a vendor for each, because I only have verified detail on Claude Code.
Approval modelConvenienceWhere secrets can poolMain safeguardApprove each command, no memoryLow, constant promptsTerminal history onlyDeveloper attentionSession-scoped approvalMediumSession logsRule expires when the session endsPersistent per-repository allow rule (Claude Code’s standing option)HighA settings file inside the projectIgnore rules, deny rules, scanningSandboxed execution with scoped credentialsHigh once configuredSandbox configurationThe agent never holds the real secretOrg-managed policyMediumCentral policy storeAdmins set allow and deny lists for everyone
The persistent rule is the sharpest trade-off. It buys the most speed and creates the one artefact that a careless commit can publish. Sandboxing attacks the root cause by keeping real credentials out of the agent’s reach. We covered one version of that approach in our report on GitHub Copilot sandboxing reaching GA in VS Code 1.141.
Historical Context: Secrets in Repositories Are an Old Problem
Leaked credentials in public repositories predate AI coding tools by many years. Hard-coded API keys, committed .env files and stray private keys have fed attackers’ scanners for as long as GitHub has been public. Platforms responded with secret scanning and push protection, which block or flag known credential formats at commit time.
What is new here is the source of the leak. Earlier waves came from code, where a developer typed a key into a source file. This wave comes from tool state, a configuration file a program writes on the developer’s behalf. Developers watch their source files closely and rarely audit dotfiles that a tool creates automatically.
Scanners also lag on this pattern. A password embedded in a command string inside a JSON allow rule does not look like a standard token format, so pattern-based tools can miss it. Plain database passwords are the clearest example, and they make up the largest named category in Apiiro’s results. Our cybersecurity coverage has tracked the same weakness across other tooling this year.
Market Impact for AI Coding Tools and Their Buyers
No outlet has reported a financial effect from this story, and I will not invent one. No customer cancellations, stock moves or analyst notes appear in the sources. The real impact is on procurement questions, and that is analysis rather than reported fact.
Read nextClaude API Pricing: 13 Steps, Up to 90% Off [2026]AI & Machine Learning · Nov 6
Security teams evaluating agentic coding tools now have a concrete, named failure mode to put in a questionnaire. Where does the agent persist approvals? Can an administrator forbid standing approvals for shell commands? Does the vendor scan or redact secrets before writing state to disk? Vendors that answer those questions well will have an easier sales cycle this quarter.
The story also lands while engineering leaders are wrestling with agent governance more broadly. Our earlier piece on AI coding agents and a 49% jump in PR merge time showed teams adding review layers around agent output. A secrets-in-dotfiles finding gives those teams one more reason to add an automated gate, not another manual step.
The Australian Angle: OAIC, ASD and Essential Eight
Australian organisations should treat an exposed credential as a potential incident, not a housekeeping task. The OAIC’s guidance on responding to data breaches follows three moves. Contain the breach, assess the facts and the likely harm, then notify affected individuals and the OAIC if required under the Notifiable Data Breaches scheme.
A leaked key is not automatically a notifiable breach. The test turns on what the credential unlocked, whether personal information was involved and whether serious harm is likely. A database password that fronts customer records is a very different case from a token for a throwaway test environment. Document the assessment either way, because regulators ask how you reached your conclusion.
Supply-chain exposure through third parties has been a recurring theme locally. The Who Gives A Crap breach through a marketing software vendor showed how far a single upstream weakness can travel. Teams that already map their controls to the Essential Eight can slot secrets hygiene into existing work. Our guide to the Essential Eight maturity model shows how to structure that mapping.
9 Fixes to Apply Today
The order matters. Stop new leaks first, then find old ones, then rotate whatever you find.
Stop the leak
Add .claude/settings.local.json to your .gitignore, and to a global ignore file so every new repository inherits it.Open the file in each active project and read every allow rule. Delete any rule that contains a password, token or key.Replace embedded secrets with environment variables or a secret manager reference, so the command text never carries the value.
Find and clean up old exposure
Run the three Git commands shown earlier to see whether the file was ever tracked.Scan the full history, not just the current tree. A tool such as Gitleaks can do this with gitleaks detect --source . --log-opts="--all".Turn on GitHub secret scanning and push protection for every organisation repository you own.
Lock down the agent and the credentials
Add deny rules for .env files, cloud config directories and any secrets folder, following Anthropic’s published example.Prefer narrow allow rules over wildcard command families, and use ask rules for anything that pushes, deploys or deletes.Rotate every credential that touched a public repository. Revoke first and investigate second, since removing a file from history does not un-leak a secret that scrapers may already hold.
Rotation is the step teams skip, and it is the only one that actually closes the exposure. Credential theft by infostealer malware shows how fast stolen secrets get reused, as we found in our guide to protecting passwords from infostealers. Assume anything that sat in a public file is already copied.
Predictions: 4 Calls for the Next 12 Months
These are my forecasts, not reported facts, and any of them could miss.
Vendors will add secret redaction to saved approvals. The fix is cheap to build and the criticism is specific. I expect at least one major AI coding tool to mask or refuse to persist commands that match credential patterns.Secret scanners will add agent config formats. Detection rules for allow-rule JSON and similar files will become standard in scanning products within the year.Enterprise buyers will demand admin-level controls over standing approvals. Expect procurement checklists to ask whether administrators can disable persistent shell approvals centrally.Researchers will publish follow-up scans of other agent tools. Apiiro’s method is easy to copy. Other vendors’ state files will face the same public scrutiny.
The common thread is that the pressure now sits on tool state, not just source code. Teams that audit agent configuration the way they audit application code will be ahead of whatever vendors ship.
What This Means for Australian Dev Teams
The practical read is calm but firm. The scale is limited, about 1,122 files out of 103,617 public repositories scanned, and the cause is a workflow gap rather than a proven product-wide leak. The consequences for any single affected team can still be severe, because a database password or AWS key is a live credential the moment it is public.
Start with a ten-minute audit across your active repositories. Check for the file, check your ignore rules and read the saved allow rules. If you find a secret, rotate it today and document the decision for your privacy and security leads. Anthropic may well tighten the feature. Until then, the controls above are in your hands.
Frequently Asked Questions
What does “Yes, and don’t ask again” do in Claude Code?
It approves the current command and can save it as an allow rule in .claude/settings.local.json, so the tool stops prompting for that command. If the command contained a password, key or SSH credential, the saved rule contains it too.
How many secrets did Apiiro find?
Per the reports, Apiiro found 1,122 public GitHub files with at least one secret, covering at least 1,379 distinct secrets, across 103,617 public repositories. Named categories included 379 database passwords, 43 SSH credentials, 42 VCS tokens and 23 AWS access keys.
Did Anthropic confirm or fix the problem?
No on-record Anthropic comment appears in the sources reviewed. Claims that the company acknowledged the issue, shipped a fix or issued a security advisory are unconfirmed as of November 8, 2026.
Were the exposed secrets used by attackers?
The reporting does not say so. It describes exposure in public repositories, not confirmed intrusions. Treat any exposed credential as compromised anyway and rotate it.
How do I check whether my repository is affected?
Run git ls-files .claude/settings.local.json to see if Git tracks the file, and git log --all -- .claude/settings.local.json to see whether it ever did. Then scan the full history with a secrets scanner and read the allow rules in the file itself.
Is a leaked API key a notifiable data breach in Australia?
Not automatically. Under the OAIC’s Notifiable Data Breaches guidance, the question is what the credential unlocked, whether personal information was involved and whether serious harm is likely. Assess, document and notify if the threshold is met.
Should teams stop using Claude Code?
The sources do not call for that. They point to repository hygiene and credential handling. Use narrow allow rules, add deny rules for secret files, ignore the local settings file in Git and keep real credentials out of command lines.More on this topicCybersecurityCloud ComputingSoftwareAI & Machine LearningTrending now*SSHole OpenSSH Flaw: 1,024-Char Password Bypass [2026]Qantas and 5 Airlines Probe Amadeus Breach [2026]Set Up Google Authenticator on PC: 12 Steps, 70 Min [2026]Tungkillo Fury: 3,300-Member Group Warns Labor [2026]Oracle Falls 4% as Microsoft Reportedly Ends AI Deal [2026]
Sophie LawsonCybersecurity EditorSophie Lawson covers cybersecurity, VPNs and privacy software for Tech Insider Australia. A former IT systems administrator, she translates complex security topics into plain-English advice and personally tests every tool she recommends.View all articles
——————————————————-
Click Here For The Original Source.
