Apiiro finds 1,122 public GitHub repos leaking credentials via Claude Code’s “don’t ask again” permission setting

Apiiro finds 1,122 Claude Code files exposing credentials on GitHub

Enterprise cybersecurity firm Apiiro has identified 1,122 publicly accessible Claude Code configuration files on GitHub that expose passwords, API keys and other credentials. The exposure traces to the “Yes, and don’t ask again” option in Claude Code, Anthropic’s autonomous coding assistant. According to VentureBeat’s reporting of the investigation, the option does not save an abstract permission. It saves the full approved command string, and any credentials written into that command, to a local configuration file. The affected repositories belong to individual developers and enterprises, and the exposed material includes active database logins and cloud infrastructure credentials.

For Australian environmental professionals, this is not a remote IT problem. Many consultancies now write their own scripts for laboratory data imports, GIS automation, cloud dashboards and sampling databases, and some may be using AI coding agents to build and maintain them. Systems like these can hold client site data, laboratory results, borelogs, monitoring records and, in some cases, personal information about landowners, tenants and staff. Developers, lawyers and councils who commission contamination work or share data with consultants have a direct interest in how that data is protected.

The finding also marks a change in where AI risk sits. Much of the discussion about AI tools in professional services has focused on the accuracy of model outputs. This disclosure shows that the more immediate exposure can come from how an agent stores its own configuration and permissions. A convenience setting, used as designed, has placed working credentials on the public internet.

How the “don’t ask again” setting stores secrets in plaintext

Claude Code asks users to authorise terminal operations before it runs them. Typical examples include debugging a backend service, running a database migration or calling a cloud API. To avoid repeated approval prompts, developers often select “Yes, and don’t ask again”. Apiiro found that Claude Code then writes the complete, unredacted command string into either .claude/settings.local.json or .claude/settings.json. If the command contained a hardcoded database password, a cloud API token or an SSH key, that secret is stored in plaintext in the configuration file.

The two files behave differently, and the difference matters. The settings.local.json file is intended to stay on the developer’s machine, and Claude Code attempts to add it to .gitignore automatically. Apiiro reported that this protection is frequently defeated by repository restructuring, subdirectories being moved, or the file already being tracked by Git before the ignore rule took effect. The settings.json file is designed to be shared across a team and committed to the repository, so any credential written there travels with the code every time it is pushed.

Standard secret scanning tools did not catch all of the exposures. Apiiro reported that Gitleaks and TruffleHog, two widely used scanners in CI/CD pipelines, failed to flag 215 of the exposed credential sets. The secrets were embedded inside nested command argument strings rather than appearing in recognisable token headers or key formats, which is what these scanners are built to detect. An organisation relying solely on automated scanning could therefore believe its repositories were clean when they were not.

Deleting the configuration file does not fix the problem. The plaintext secrets remain in Git commit history, and any forks or clones made while a repository was public may still hold them. Every credential found in these files should be treated as compromised, revoked and reissued before the commit history is purged with a tool such as git filter-repo. Anthropic’s Head of Claude Code, Boris Cherny, told VentureBeat the team is “exploring improvements, including built-in scanning for exposed credentials”. Until such a feature is released, responsibility for detection and remediation sits with the organisations using the tool.

The disclosure sits against a wider governance gap. A VentureBeat Pulse enterprise security survey found that 24% of organisations deploying AI agents run them on shared credentials or personal service accounts, and 20% have no automated mechanism to detect unauthorised agent actions.

Privacy and confidentiality obligations for Australian consultancies

For Australian organisations, a leaked credential can quickly become a privacy compliance matter. Where an exposed database or cloud system holds personal information, organisations covered by the Privacy Act 1988 (Cth) need to assess whether the exposure is an eligible data breach under the Notifiable Data Breaches scheme. That assessment considers whether unauthorised access is likely to result in serious harm, and it runs to statutory timeframes. A publicly exposed database password is not automatically a notifiable breach, but it does trigger the obligation to assess, and the clock starts when the organisation becomes aware of reasonable grounds to suspect an eligible breach.

In professional services, confidentiality obligations often extend well beyond personal information. Environmental consultancies hold commercially sensitive material under engagement terms: pre-acquisition investigation results that bear on purchase price, monitoring data subject to regulator correspondence, and information prepared for legal proceedings. An exposed credential that opens a project database or a cloud storage bucket could expose that material regardless of whether it contains personal information. Clients who share data under confidentiality, including law firms instructing expert witnesses, should expect their consultants to manage credentials with the same discipline they apply to document control.

The survey figures on shared credentials are also relevant to Australian practice. Smaller consultancies and project teams can face the same pressures. Where one login is shared across a team or used to run an automated agent, it becomes harder to trace who or what accessed a system, and harder to revoke access cleanly if that credential is exposed.

References and related sources

• Primary source: venturebeat.com
• o16g.com
• venturebeat.com
• https://venturebeat.com/security/did-claude-codes-dont-ask-again-option-accident

How iEnvi can help

iEnvi integrates technology and data-driven approaches into environmental consulting. We monitor AI and technology developments that affect how environmental professionals deliver services to clients.

• Our capabilities
• About iEnvi
• Talk to the team

This is an iEnvi Machete news summary. Prepared by iEnvi to summarise the source article for environmental professionals tracking AI, data, and technology developments that affect consulting and project delivery.

Published: 10 Nov 2026

Need advice on this topic? Speak to an iEnvi expert at info@ienvi.com.au or 1300 043 684, or contact us online.