Claude Code trust bypass shows how old config flaws still matter

At a glance

What this is: This is Sonar’s analysis of two pre-trust execution flaws in Claude Code that could let malicious project content run code before the tool’s trust dialog was accepted.

Why it matters: It matters because AI agent governance now has to cover local project settings, repository trust, and execution boundaries, not just model prompts and tool permissions.

By the numbers:

• Anthropic's Claude Code CLI has become an increasingly popular tool for developers, driving over 10 million weekly downloads on NPM.

👉 Read Sonar's analysis of the Claude Code trust bypass and pre-trust execution paths

Context

Claude Code is an AI-assisted developer tool that expands what a local workspace can do, which also expands the attack surface of any repository the user opens. In this case, the problem was not model output quality but pre-authorisation execution paths hidden in Git configuration and project settings.

Agentic tools create a governance gap when they trust local files, commands, or hooks before the user has explicitly accepted the workspace. That is a direct NHI and agentic AI concern because the agent is effectively operating with delegated runtime privileges inside a development environment.

Key questions

Q: What breaks when an AI coding assistant executes project content before trust is confirmed?

A: The trust model breaks because repository content becomes a covert execution channel. A malicious project can trigger helper commands, hooks, or Git-related behavior before the user approves the workspace, which makes the trust dialog ineffective and can expose the developer machine to arbitrary code execution.

Q: Why do AI coding agents increase trust risk in developer workspaces?

A: They can write repository state that other tools later treat as trusted configuration or executable input. That creates a trust transfer from a constrained agent session to a more privileged automation layer. The risk grows when tools auto-discover repositories and run helpers without user confirmation.

Q: What do security teams get wrong about read-only defaults in agentic tools?

A: Read-only defaults reduce post-launch damage, but they do not stop code that runs before the main permission model applies. Teams often assume the permission banner is the control, when the real risk is any helper process or parser that executes first.

Q: How should teams verify trust gates in AI-enabled developer workflows?

A: They should test with hostile repositories that contain Git config tricks, local settings, and hook payloads, then confirm nothing executes until approval is complete. The control is only real if it blocks every pre-trust command path, not just the obvious one.

Technical breakdown

Pre-trust execution in developer toolchains

The core issue is not the AI model itself but the sequence of startup actions around it. If a tool inspects a repository, reads project metadata, or calls helper commands before the trust prompt, an attacker can place code in configuration paths that execute first. In this case, Git features such as fsmonitor and gpg.program could trigger command execution during routine status or signature checks. The security control failed because trust was treated as a later user decision rather than a hard gate for all command execution.

Practical implication: move every command-launching or config-loading path behind explicit workspace trust.

Local project settings as a code execution path

Project-scoped configuration is often assumed to be data, but in agentic tools it can become executable policy. The article shows that .claude/settings.json could define apiKeyHelper or hooks that run shell commands at startup, which means local settings can override safer global defaults. This is a classic trust-boundary mistake: the system treats repository content as administrative input before the workspace has been verified. Once that happens, arbitrary code can run without any model prompt being involved.

Practical implication: classify project settings as executable inputs and validate them only after trust is established.

Why read-only defaults are not enough

Read-only permissions reduce damage after the tool is running, but they do not stop pre-trust code execution. The attack chain here shows that the compromise occurs before the main permission model is even relevant, which is why agent governance has to include startup sequencing, repo provenance, and helper command suppression. This is where AI agent identity and NHI governance intersect: the tool is acting as a delegated runtime identity, and delegated identities need lifecycle controls as much as access controls.

Practical implication: pair least privilege with startup hardening, provenance checks, and execution allowlists.

Threat narrative

Attacker objective: The attacker wanted to execute arbitrary code on the developer’s system before trust approval and use that foothold to compromise the local environment.

1. Entry occurred when a victim opened Claude Code inside a malicious repository or project folder that contained crafted Git and local settings.
2. Credential access was not the primary objective here; the attacker instead abused pre-trust command execution paths to run arbitrary code before the trust dialog.
3. Impact followed as the malicious code could compromise the developer’s machine and environment, creating a full local foothold before user approval.

NHI Mgmt Group analysis

Pre-trust execution is the real governance gap in agentic developer tools. The security conversation often focuses on prompt injection, but this case shows that ordinary configuration files can be more dangerous than model prompts when they are processed too early. Once a tool treats repository contents as trustworthy before the user has accepted the workspace, the trust model collapses. Practitioners should treat pre-trust execution paths as a first-class control failure, not an implementation detail.

Agentic AI security now depends on classic software trust boundaries, not just AI-specific controls. The article demonstrates that Git hooks, helper scripts, and local settings can become covert execution channels in AI-enabled workflows. That means OWASP Agentic AI Top 10 style concerns and traditional secure development hygiene now overlap in the same control surface. Teams that split AI governance from developer-tool security will miss the shared failure mode.

Workspace trust gate integrity: this is the named concept this incident sharpens, because the issue is not whether a trust dialog exists but whether any executable path can run before it. If commands, hooks, or local settings are evaluated first, the gate is decorative rather than protective. The practitioner conclusion is straightforward: verify that trust gates are hard enforcement points, not advisory prompts.

This is an NHI governance problem as much as a developer tool problem. Claude Code functions like a delegated runtime identity with access to files, commands, and helper processes inside a workspace. When that identity can be influenced by untrusted project content, lifecycle and execution boundaries matter more than static permission defaults. Teams should govern the agent as an identity-bearing runtime, not as a simple CLI utility.

What this signals

Agentic developer tools are becoming part of the enterprise identity plane, because they execute with delegated access and can be steered by untrusted content. The practical signal is that workspace trust, child-process control, and project provenance now belong in the same review cycle as secrets management and least privilege. See also OWASP Agentic Applications Top 10 and the NIST AI Risk Management Framework.

Workspace trust gate integrity: this incident shows that the most important control is the one that prevents any executable content from running before approval. If your tooling can process hooks, config files, or helper scripts before trust is established, you have a governance gap rather than a model-risk problem.

For practitioners

• Audit every pre-trust execution path Review any startup routine that reads repository content, launches helper commands, or evaluates local project settings before workspace trust is confirmed. Block shell execution until the user has explicitly approved the folder.
• Separate data parsing from command execution Treat Git config, hooks, and agent settings as untrusted inputs until validation is complete. If a setting can execute code, move it into a post-trust allowlisted path and log every invocation.
• Harden developer workstation provenance checks Require source verification for unfamiliar repositories before opening them in AI-enabled developer tools. Pair that with endpoint controls that restrict unexpected child processes spawned by code assistants.
• Test the trust gate with malicious fixtures Use seeded repositories containing fsmonitor, gpg.program, apiKeyHelper, and hook-based payloads to confirm that no command runs before trust approval. Validate both the UI prompt and the backend enforcement.

Key takeaways

• This incident shows that AI agent security failures can originate in ordinary configuration handling, not just in prompt injection or model misuse.
• The evidence points to a simple but serious control gap: pre-trust command execution can bypass a trust dialog and compromise the local environment.
• Teams should test AI-enabled developer tools for startup sequencing, executable settings, and repository provenance before expanding deployment.

Key terms

• Pre-Trust Execution: Code or commands that run before a user has approved a workspace, repository, or project context. In agentic tools, this creates a hidden execution channel because safety prompts arrive too late to block malicious configuration or helper logic.
• Workspace Trust: A trust control in code editors that separates passive file viewing from active execution of project-defined tasks. When disabled or bypassed, the editor can run repository instructions in the user’s context, which turns source control content into an execution path.
• Delegated Runtime Identity: A non-human identity assigned to an AI system or workflow so it can act within a defined boundary. The identity carries credentials, tool permissions, and logging obligations that determine what the system may access and how its actions are traced.

What's in the full article

Sonar's full article covers the operational detail this post intentionally leaves for the source:

• The exact Git configuration paths used to trigger pre-trust execution in Claude Code.
• The .claude/settings.json settings that ran shell commands before the trust prompt.
• The patch changes in v2.0.71 and how they moved execution behind the trust gate.
• The mock attack flow demonstrating how a malicious repository could compromise a developer workstation.

👉 The full Sonar article covers the exploit mechanics, patch details, and attack reproduction steps.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and secrets management. It helps security and identity practitioners build durable controls for delegated runtime access and lifecycle governance.