Claude Code 2.1.143 Turns Plugin Dependencies and Background Sessions Into Things You Can Govern

Claude Code 2.1.143 is not the release that will make a launch video go viral. Good. The interesting work in coding agents right now is not another sparkling demo of a model editing five files at once. It is whether the runtime can survive plugin graphs, background workers, MCP configs, worktrees, permission modes, and developer machines that go to sleep at the worst possible moment.

That is what makes this patch worth reading. Anthropic added plugin dependency enforcement, projected context-cost estimates in the plugin marketplace, more state preservation for background sessions, safer worktree cleanup, and several Windows and PowerShell changes. None of those are glamorous. All of them are the kind of control-plane details that decide whether an agent is a useful teammate or a clever process with amnesia.

Plugin systems eventually become package managers

The headline feature is deceptively small: claude plugin disable now refuses to disable a plugin if another enabled plugin depends on it, and it prints a copy-pasteable disable-chain hint. Conversely, claude plugin enable now force-enables transitive dependencies. That sounds like ordinary dependency hygiene because it is. It is also exactly the line a plugin ecosystem has to cross before teams can govern it.

A plugin in Claude Code is not just a theme pack. The plugin docs describe a surface that can package skills, agents, hooks, MCP servers, settings, binaries, and language-server integrations. In other words, a plugin can change instructions, add tools, alter runtime behavior, and connect the agent to systems outside the repo. If disabling one plugin silently breaks another, or enabling one plugin invisibly drags in a chain of capabilities, the security model becomes folklore.

This release moves that surface closer to something engineers already understand: dependency graphs. That does not solve supply-chain risk by itself, but it gives operators an object to reason about. Which plugin introduced this MCP server? Which skill depends on that shared package? What has to be disabled together during an incident? Without dependency enforcement, the answer is usually “ask the one person who installed it and hope they remember.” That is not a governance strategy; it is archaeology.

Context cost is not just a billing concern

The plugin marketplace now shows projected context cost — both per-turn and per-invocation token estimates. This is one of those features that looks like a wallet guardrail but is really an engineering signal. Context is budget, latency, attention, and risk all at once.

A plugin that injects heavy instructions into every turn may be worth it if it encodes team-specific deployment policy. It is probably not worth it if it adds a thousand tokens of generic “be helpful” boilerplate. A tool that adds large per-invocation context may produce better answers, but it also increases latency and can push useful project state out of the model’s working set. For organizations trying to standardize agent usage, “how expensive is this plugin in every interaction?” belongs in the install decision, not the finance postmortem.

There is also a data-exposure angle. More context usually means more material being assembled, transformed, and passed through the runtime. Even when the model endpoint is approved, teams still need to know which plugin caused which information to be included. A marketplace cost estimate is not an audit log, but it nudges developers toward the right question before they add another always-on extension to the agent’s brain.

Background agents need boring state guarantees

The operational core of 2.1.143 is background-session state. Anthropic says background sessions now preserve the model and effort level after waking from idle. /bg now preserves MCP config, settings, added directories, plugin directories, strict MCP config, fallback model, and permission-related options across respawn and detach paths. Background sessions launched from claude agents also honor permissions.defaultMode from settings instead of being overridden to auto mode.

This is not polish. If a foreground session has one MCP configuration and a background worker wakes with another, the team no longer has a clean story about what ran. If the selected model, effort level, fallback model, or permission posture changes during detach and wake, debugging becomes indistinguishable from superstition. The hardest failures in agent systems are not always wrong answers. They are wrong answers produced under a runtime state nobody can reconstruct.

The release also fixes repeated stop hooks by ending the turn with a warning after eight consecutive blocks, configurable through CLAUDE_CODE_STOP_HOOK_BLOCK_CAP. That cap matters because hooks are where teams often encode policy: tests must pass, a secret must not be written, a tool call must be reviewed. A hook that can trap a session forever is not a control; it is a denial-of-service bug wearing a compliance badge.

The dangerous flags deserve adult supervision

Several changes reduce friction for legitimate automation while increasing the need for explicit policy. Claude Code now supports worktree.bgIsolation: "none", allowing background sessions to edit the working copy directly without EnterWorktree for repositories where worktrees are impractical. That is useful. It also lowers isolation, which means teams should treat it as a repo-level decision rather than a casual personal preference.

The PowerShell tool now passes -ExecutionPolicy Bypass by default, with CLAUDE_CODE_POWERSHELL_RESPECT_EXECUTION_POLICY=1 available for users who want to opt out. On Windows, the PowerShell tool is enabled by default for Bedrock, Vertex, and Foundry users unless CLAUDE_CODE_USE_POWERSHELL_TOOL=0 is set. Again: sensible product ergonomics, but not something security teams should discover after the fact. Managed Windows environments often have execution-policy expectations for a reason.

The release also continues the recent work around --dangerously-skip-permissions. Anthropic fixed one path where claude agents --allow-dangerously-skip-permissions defaulted dispatched sessions into bypass mode instead of merely making it available in the permission cycle, while also preserving bypass availability across detach paths. That distinction matters. Making a break-glass mode available is different from silently launching work in break-glass mode.

The best fix in the list may be the least flashy: worktree cleanup no longer falls back to rm -rf when git worktree remove fails, preventing loss of gitignored or in-progress files. That is exactly the kind of defensive engineering agent runtimes need more of. Trust is built when cleanup paths refuse to be clever with user data.

For teams using Claude Code seriously, the rollout checklist is straightforward. Upgrade if you use plugins, the marketplace, /bg, agent view, MCP configs, Windows, PowerShell, or background sessions after laptop sleep. Then test the state transitions: enable a plugin with dependencies, try to disable a dependency, inspect context-cost estimates, detach and wake a background session with non-default model and effort, verify MCP config persistence, simulate a failed worktree cleanup, and review whether PowerShell execution-policy bypass is acceptable in your environment.

The broader point is that Claude Code is becoming less like a single terminal assistant and more like a developer-agent runtime. Runtimes are judged by their dullest edges: dependency resolution, state persistence, permissions, cleanup, and observability. Version 2.1.143 is a good release because it spends its budget there.

Sources: Claude Code GitHub release v2.1.143, Claude Code agent view docs, Claude Code plugin docs, Claude Code MCP docs