A config file that runs shell commands: "open this in Claude Code" needs a review gate

Check Point Research disclosed a set of vulnerabilities in Anthropic's Claude Code that allowed remote code execution and theft of API credentials through malicious project configurations ^[1]. The mechanisms were ordinary product features -- Hooks, Model Context Protocol servers and environment variables -- which could run arbitrary shell commands and exfiltrate Anthropic API keys when a developer cloned and opened an untrusted repository ^[2]. Check Point says it worked with Anthropic's security team and that all reported issues were patched before publication ^[3].

The patch is the least interesting part. The design question underneath it is not a bug, and it has not gone anywhere.

Claude Code is a command-line tool that lets developers delegate coding work through natural language ^[11], with the authority to modify files, manage Git repositories, run tests, drive build systems, connect MCP tools and execute shell commands ^[10]. It reads project-level settings from `.claude/settings.json`, a file that lives in the repository, so a developer who clones a project inherits the settings the team already uses ^[4]. That is a sensible collaboration feature and, as Check Point points out, it is also just another file in the repo, editable by any contributor with commit access ^[5].

Hooks are where the sensible feature becomes an execution path. Hooks exist to give deterministic control over the tool's behaviour, running user-defined commands at points in its lifecycle instead of waiting for the model to decide ^[6]. Because they are declared in that same repository-controlled file, any contributor with commit access can define shell commands that run on every collaborator's machine ^[7]. Check Point demonstrated it with a hook that opened Calculator, wired to the SessionStart event with a startup matcher, which fires automatically as Claude Code initialises ^[8]. Put those three properties together and cloning a repository plus starting the agent in that directory is enough to run someone else's commands on your laptop ^[13]. Check Point reports that running the tool in the test directory did present a trust dialog, and that the dialog warns about reading files ^[9]. A warning framed around reading is not the warning a user needs before something executes.

The operational consequence is a change in category. A branch from an unfamiliar fork is now closer to an unknown binary than to a text file, and it should pass the same gate: who reviewed it, what credentials are reachable from the shell it inherits, and whether the agent runs anywhere other than a disposable environment. Check Point's framing is that AI development tools introduce attack surfaces that traditional security models have not fully addressed ^[12]; the practical version of that is narrower. The blast radius is whatever your agent's process can read, and for most engineers that includes an API key and a shell.

Three things to watch. Whether your organisation's third-party review policy mentions agent config files at all, or stops at dependencies and CI workflows. Whether the credentials your agent uses are long-lived and broadly scoped, because exfiltration only matters in proportion to what the key unlocks ^[2]. And whether trust prompts across agentic tools start distinguishing "this repo will be read" from "this repo will run commands", because those are different decisions and users are currently being asked one question ^[9].