Extensions That Rewrite the Core Won't Take the Whole Session Down When They Break — Claude Code v2.1.289 Adds a "Firewall" to the Door It Just Opened

A Door Just Opened, and the Next Day Brings Reinforcements

On October 3, Anthropic released Claude Code v2.1.289. "Mods," introduced just before in v2.1.287 (October 1), is a mechanism that runs code written in JavaScript/TypeScript inside the Claude Code process itself, letting you swap out internal behavior down to tool calls, prompts, and screen rendering. While the freedom this gives extensions jumped all at once, it also left a lingering worry: "What happens if code running inside the core breaks?" v2.1.289 is an update that tackles that worry head-on.

This release centers less on adding new features and more on "isolation" that contains the damage from a broken extension, and plugging the holes in permission rules that had been slipping through. It isn't flashy, but for anyone running agents unattended and always-on, the changes lined up here carry a lot of weight.

A Broken Extension No Longer Takes the Whole Session Down With It

Until now, if a Mod threw an error partway through drawing the screen, the entire session could end in an "unrecoverable interface error." v2.1.289 cuts off this collateral damage one case at a time. Here are the key points, based on the official changelog.

• Fail a rendering exception on its own: Even if a Mod's display layer (Client) throws an exception mid-render, only that piece fails and raises ui.fault, while the surrounding rendering and the session survive.
• Contain async exceptions and runaway regions: Even if a Mod's screen handler throws an exception asynchronously, or a zero-height display region keeps growing without bound, supervised and background sessions no longer terminate.
• The engine covers for values it can't draw: If a value returned by a Mod's ui.render causes a line to fail to draw, the engine draws its own line in its place and keeps the session going.

Alongside this, several extension-related rendering glitches have been fixed individually—text containing tabs or control characters spilling onto the line below, a band briefly failing to draw and shoving a card aside, and right-aligned content overlapping the close button.

Extensions Can Now Add "Coworkers"

Even as the isolation was hardened, what Mods can do has also expanded. In v2.1.289, agent.spawn was added for plugins, letting a Mod launch an agent that becomes a teammate. The same agent ID can now be used across all of a plugin's hook events, and $.agent.list() gained "idle" and "waiting" states. This lays the groundwork for extensions to orchestrate multiple agents running in parallel and to read their states.

Chasing a Slipped-Through 'rm -rf' Even Behind an Environment Variable

On the security side, a "loophole" in how the sandbox automatically allows safe commands has been closed. Until now, deny/ask rules meant to block or confirm dangerous commands could be bypassed with the following patterns.

• Hiding behind an environment-variable prefix: placing an environment variable with an expanding value in front of the command, as in TZ="$HOME" rm -rf build.
• A leading variable assignment: when a standalone variable assignment is wedged in front of the command.

v2.1.289 makes sure these aren't missed and that the rules still apply, even under the sandbox's auto-allow. In addition, a bug where Read deny rules weren't applied to files referenced, modified, or selected via @ through a symlink has been fixed, as well as an issue where a user-installed plugin could rewrite the description of the sign-in tool for an org-managed MCP server. The direction here is to widen what extensions can do while not letting them cross the lines an organization has drawn.

The "Same Key" You Trade for Convenience Is Still Right There

Even with isolation and hole-plugging in place, the fundamental risk of Mods hasn't gone away. As Anthropic itself states plainly, Mods are not sandboxed and run with the same permissions you have. On top of reading and writing files, launching processes, and network communication, they can even read API keys placed in environment variables or config files. By design, only the permission prompts shown to the user can't be rewritten—but as has been pointed out, that also means that's the only hard boundary. It bears noting that what v2.1.289 protects is "a broken extension won't crash the session," not "a malicious extension can't do anything."

There are ways to check before installing. claude plugin validate lets you list the events a Mod handles and the operations it requests, --safe-mode temporarily suspends all customizations, and for organizational use, admin settings can restrict user-installed Mods. Anthropic's warning is consistent: "Install only from trusted authors and marketplaces."

What It Means for Unattended, Always-On Operation

The value of this update becomes clear in settings where agents run for long stretches, unattended. The fact that supervised and background sessions no longer grind to a complete halt over a single extension's rendering bug ties directly to uptime in always-on operation. You could say that designing automation with extensions "left installed" has become a bit more realistic.

At the same time, the more an extension's powers grow—like with agent.spawn—the heavier the judgment of "which Mod do I entrust my permissions to" becomes. In real-world use, the safe approach is to make a habit of starting with official samples and pre-checks via plugin validate, and, in organizations, to set a default line in admin settings for which extensions can be loaded. The wider you open the door, the more the inspection at the entrance pays off.

References: Claude Code Docs — Changelog (v2.1.289) / Releasebot — Claude Code updates / AI TLDR — Claude Code 2.1.289 / Mixed News — Claude Code mods are not sandboxed