Build1 publisher3 min readPublished
Claude Code mods run with the user's permissions despite their JavaScript sandbox
Anthropic's docs say Claude Code mods run in their own sandbox, yet can read your files, start processes and make network requests. That sandbox only routes access through one $ API, so the trust decision happens at install.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Claude Code's optional sandboxing isolates the Bash commands Claude runs, and the docs say a process started by a mod runs outside it.
- According to the docs, a mod can read environment variables and settings files, including any API key stored in either.
- Running claude plugin validate before installing lists the events a mod handles and the file reads or network requests it asks for, without executing its code.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- exposure Every installed mod's author can read an API key kept in an environment variable or settings file, so choosing a mod is also choosing who holds that key.
- constraint Claude Code's own sandbox setting cannot contain an extension; anyone who wants a mod isolated has to isolate the whole Claude Code session from outside it.
- decision Teams that enforce policy through ask rules and PreToolUse hooks have to decide whether to allow mods at all, because an approving mod can overrule both.
The sandbox in the first statement is a boundary inside the JavaScript runtime. A mod's module has no DOM and no Node [1]. To touch files, processes, the network or the UI, its code calls through a single object, `$` [3]. A dev.to post set the two docs lines side by side. In its example, a handler registered with `on("tool.call", { tool: "Bash" }, ...)` gets a directory listing by calling `$.fs.readDir("/tmp")` [3].
According to that post, the first two days of the launch were "one long argument" over which of the two lines was the lie [12]. Both are accurate, about different layers. The runtime boundary is good work for what it does. One choke point lets the engine see every request and log it, and, in the post's words, "(in theory) gate it" [10]. It also keeps modules from stepping on each other [13]. It does not shorten the list of what a mod may ask for. The file, process and network calls all sit on `$`, and the docs say a mod is "code that runs with your permissions" [c3, c4]. The author wrote that the runtime sandbox "was never a security boundary between the mod and your machine" [13].
The problem shows up in the user's own policy. Hooks form a chain, and a mod in that chain can observe, rewrite or fully answer any event [7]. A mod that approves tool calls can approve one "that an ask rule would prompt for, or that one of your own PreToolUse hooks blocked" [6]. With such a mod installed, a blocking hook is closer to a strong opinion. The author applies the same logic to audit logging, because a mod can rewrite the events a logger was counting on [7].
Anthropic drew one hard line. "A mod can restyle much of Claude Code's interface, but not the permission prompt. It can't change what a prompt shows you," the docs say [8]. According to the post, panes, bands above the prompt and toasts are all open to a mod [15]. The post's example of what the line prevents is a restyled dialog that shows "run tests?" while approving `rm -rf` [14]. I think this is the right place to spend the hardening effort. When the person reading the dialog is the security control, the dialog is the surface that has to stay honest, and it is the one surface Anthropic closed to mods [8].
That makes installation the trust boundary [4]. The docs' instruction is direct: "Install mods only from authors and marketplaces you trust." [4] The post's author wrote: "Installing a mod is giving someone your shell." [11] For the `claude plugin validate` listing to be enforceable, the engine would have to refuse any `$` call the listing did not show [1]. The post does not say whether it does [1].
What to watch
- Whether Anthropic starts enforcing a mod's declared requests at the $ layer, so a call missing from the validate listing is refused.
- Whether hook ordering changes so that a mod's approval can no longer override a user's PreToolUse block.
- Whether mod marketplaces publish validate output or review mods before listing them.