Claude Code 2.1.142 Makes Background Agents Configurable Enough to Become Policy Objects
Claude Code 2.1.142 looks like a patch release until you read it like an operator. Then the shape is obvious: Anthropic is turning background agents from “that session I launched earlier” into configurable policy objects. That is a much bigger deal than another handful of CLI flags.
The headline change is the expansion of claude agents dispatch options. Background sessions can now be launched with explicit directories, settings, MCP configuration, plugin directories, permission mode, model, effort level, and, yes, --dangerously-skip-permissions. The release also fixes worktree detection, daemon sleep/wake behavior, plugin cache cleanup, MCP timeout handling, Windows deadlocks, and macOS upgrade crash loops. Boring? Exactly. This is the boring layer that decides whether autonomous coding work is governable or just vibes with a process ID.
The useful mental model is that every background agent now has a runtime envelope. Which folders can it see? Which MCP servers are mounted? Which plugins are available? Which permission mode applies after the daemon retires and wakes the session? Which model is allowed to spend the budget? These are not cosmetic launch options. They are the actual security and operations boundary around the work.
Flags are policy, even when they look like convenience
Early background-agent workflows could get away with inheritance. Launch from a terminal, let the child session pick up the current project state, and inspect the result later. That stops working once a team has multiple worktrees, repo-specific settings, custom MCP servers, marketplace plugins, managed permission modes, and different risk profiles per task. At that point, “whatever happened to be true in the shell” is not configuration. It is folklore with write access.
Version 2.1.142 adds the flags teams need to make that state explicit: --add-dir, --settings, --mcp-config, --plugin-dir, --permission-mode, --model, and --effort. A platform team can dispatch one agent with a narrow directory scope and a read-only MCP configuration, while another gets a higher-effort model and a different plugin set. That is how agent execution starts to look less like a terminal trick and more like a work queue.
The dangerous flag deserves its own line. claude --bg --dangerously-skip-permissions now persists across retire/wake. That is useful if you intentionally run controlled automation in a sandbox. It is also the kind of setting that should be logged, reviewed, and treated like production break-glass. Persistence is a feature when the state is correct and an incident multiplier when nobody remembers who set it.
The MCP timeout fix is an operations story
The MCP fix is easy to miss: MCP_TOOL_TIMEOUT now raises the per-request fetch timeout for remote HTTP and SSE MCP servers, instead of tool calls being capped at 60 seconds regardless of configuration. That sounds minor until an agent depends on a remote tool that legitimately takes longer than a minute. A silent cap produces flaky calls, retries, partial work, and confused operators who think their server is misbehaving.
This is the broader theme of the release. If background agents disappear after macOS sleep/wake, if an upgraded binary leaves a daemon crash-looping on a deleted path, if a pre-existing git worktree blocks edits, or if Chrome-extension state crashes a background session without a shared tab, engineers stop trusting unattended work. The model can be excellent and the product can still fail because the supervisor behaves like a prototype.
Claude Code’s agent view documentation already points in this direction. Background sessions can persist without a terminal; sessions can be working, blocked, or completed; row summaries are generated by a Haiku-class model and refresh at most every 15 seconds while active. That is an operations console, not a chat transcript. Once the UI becomes an operations surface, the runtime needs to act like infrastructure.
Plugin inventory is becoming part of the threat model
The plugin fixes are also more important than their changelog weight suggests. Root-level SKILL.md files without a skills/ subdirectory now surface as skills. /plugin details and claude plugin details now show provided LSP servers. Plugin cache cleanup no longer deletes the active version directory when metadata is missing. Advisory output names every plugin.json key that shadows a default folder.
That is inventory-plane work. Teams cannot govern plugins they cannot see. A Claude Code plugin may introduce skills, agents, hooks, MCP servers, LSP servers, binaries, and settings. The supply-chain question is no longer “did I install this package?” It is “what capabilities did this package add to my agent runtime, and under which permission mode can they execute?”
Practically, teams should upgrade if they use claude agents, remote MCP servers, plugins, macOS laptops with sleep/wake, Windows network drives, or background sessions that survive package-manager upgrades. Then test the ugly paths: dispatch into an existing worktree, sleep and wake the machine, upgrade the binary, run a remote MCP call past the old 60-second boundary, and verify permission-mode persistence after retire/wake. Do not just run the happy-path demo. Background agents fail in the seams.
The larger takeaway is simple: agent safety is not just a model property. It is runtime state. Claude Code 2.1.142 matters because it gives more of that state names, flags, and persistence rules. That is how teams move from “the agent did something” to “this specific agent, with these capabilities, under this policy, did this work.”
More flags will not make background agents safe by themselves. But implicit state is unreviewable state. On that axis, this release is a real step forward.
Sources: Claude Code GitHub release v2.1.142, Claude Code agent view docs, Claude Code plugin docs, Claude Code MCP docs