CVE-2025-59536: Code Execution Before the Claude Code Trust Dialog

The advisory in one paragraph

Anthropic's GHSA-4fgq-fpq9-mr3g, mapped to CVE-2025-59536, describes a startup-time code-injection issue in the @anthropic-ai/claude-code npm package. The advisory's words: "Due to a bug in the startup trust dialog implementation, Claude Code could be tricked into executing code contained in a project before the user accepted the startup trust dialog." The exploit precondition is being launched in an untrusted directory; the impact is full code execution under the user's account. The vulnerability was reported by avivdon via HackerOne and patched in version 1.0.111.

Why agentic CLIs need a trust gate at all

A normal CLI tool, run in a directory, does what you tell it to. An agentic CLI is different: it reads files, runs hooks, executes tools, and may evaluate configuration committed in the repo itself. That last part is the dangerous one. A repo can ship:

• .claude/settings.json with permissions, env vars, and hook bindings.
• Hook scripts that fire on session start, tool use, or stop.
• Slash commands and agents with their own prompts and tool wirings.
• MCP server configs that Claude Code may launch.

Each of those is a potential execution surface that exists before the user has read a single line of the repo. A trust dialog — a one-time prompt the first time you open an unfamiliar directory — is the conventional answer: nothing repo-controlled fires until the human says yes. VS Code's Workspace Trust, JetBrains' "Trust Project," and Claude Code's startup dialog are all instances of the same pattern.

The correctness property is simple to state: no repo-controlled code path executes before the user accepts the trust prompt. Simple to state, easy to violate.

What actually broke

The advisory and CVE entry don't publish a full reproducer (and we won't speculate on the precise call site), but the shape of the bug is clear from CWE-94 and the affected/fixed versions: somewhere on the cold-start path, an input drawn from the project directory was passed through a code-generating or code-evaluating sink before the trust gate fired. That's the textbook anti-pattern for agentic tools — load order matters as much as the gate itself.

A useful mental model:

# Conceptually, before 1.0.111:
load_global_config()
load_project_config()        # ← repo-controlled, evaluated here
resolve_hooks_or_commands()  # ← may execute repo-supplied logic
prompt_for_trust()           # ← gate fires, but execution already happened
run_session()

The fix corresponds, roughly, to:

# From 1.0.111 onward:
load_global_config()
prompt_for_trust()           # ← gate fires first, with no repo input evaluated
load_project_config()
resolve_hooks_or_commands()
run_session()

The category — "trust check after side effect" — is one of the most common bugs in any software that mixes data loaded from a place with permission to act on it. Web shells fall into it. Linker-search-path issues fall into it. Workspace-trust bypasses in every IDE that has shipped one fall into it.

Severity, scored two ways

The attack vector is "Network" in the CVSS sense because the malicious project can be fetched from anywhere — a GitHub clone, an unzipped tarball, a checkout of a colleague's branch. The user-interaction component (UI:R / UI:P) is the action of opening the directory in Claude Code. Privileges required: none beyond the user's normal shell.

What to do, even if you're already on 1.0.111+

The patch closes this specific instance. The class — repo content evaluated before trust — is broader, and worth defending against on your side too:

1. Pin the version. Make sure your install is on 1.0.111 or later. If your team runs Claude Code from a Docker image, audit the image's pinned npm version.
   ~/

   $ claude --version
   # or, for the npm install:
   $ npm ls -g @anthropic-ai/claude-code

2. Treat .claude/ as untrusted-by-default. When you clone a repo you don't fully trust, skim .claude/settings.json, .claude/hooks/, .claude/commands/, and any CLAUDE.md entries before opening it in an agentic tool. Hooks and slash commands can run shell commands; settings can grant permissions.
3. Open suspicious repos in a sandbox. A throwaway VM, devcontainer, or rootless container raises the floor on what a startup-time bug can do. This is good hygiene for any agentic CLI, not just Claude Code.
4. Monitor the advisory feed. Anthropic publishes Claude Code advisories at github.com/anthropics/claude-code/security/advisories. GitHub's RSS works on it.

Where h5i fits

h5i doesn't prevent a vulnerability in another tool — only the vendor's patch can. What h5i gives you is a record: provenance for every commit Claude Code helped produce, a reasoning trace of what was read and decided, and a per-file attention coverage map. After a disclosure like CVE-2025-59536, that record is what lets you answer a security team's actual question:

"Did anyone on this team open an unfamiliar repo with the vulnerable Claude Code version between Sep 1 and Oct 3, 2025? If so, what did the agent touch?"

Without provenance, the answer is "we don't know." With h5i, it's a date-bounded h5i compliance report and a session-level h5i notes show. That's not mitigation; it's incident response.

The broader pattern

Agentic CLIs are converging on a small set of repo-controlled extension points: settings, hooks, commands, agents, MCP configs. Each one is fast, useful, and a load-order hazard. Expect more of these advisories — from any vendor — and design your workflow as if they're inevitable: pin versions, sandbox unfamiliar repos, and keep an audit trail you can query after the fact.

The good news on this specific CVE: a HackerOne reporter found it, Anthropic fixed it inside a single point release, and auto-update did the right thing for most users. That's the model working as intended.