Source Intelligence

DisclaimerUnofficial, and not affiliated with Anthropic. Nearly all of this is read straight out of what ships: npm bundles, captured prompts, published docs. Anthropic's own notes go in verbatim, marked as theirs. The rest is my reading, and every entry carries the strings behind it. If one looks wrong, vote it down and say why.

All of v2.1.246 Home All releases olderv2.1.245 v2.1.247newer
Claude Code v2.1.246

Tool subprocesses can be launched inside a memory-capped cgroup

Not switched on
Useful3 Signal4
Sandbox Notable not in their notes

MCP servers, hooks, plugin installs and tmux sessions can run under a memory cap, dark-launched here.

Every spawn class is wired through a capped-cgroup wrapper, but the exclusion list defaults to all of them unless CLAUDE_CODE_TOOL_MEMORY_CGROUP_EXCLUDE says otherwise.

Feature flag
tengu_mcp_memory_cgroup Off in both readings

The flag server returned off for the account this site reads and for the anonymous baseline. A reading of off cannot rule out a rollout these two readings sit outside of.

This account: off · anonymous baseline: off · compiled default in v2.1.246: not a boolean we can read

Read once, for one account on one subscription tier, against v2.1.246. It isn't a statement about your account. What a flag value here can and cannot tell you

CLAUDE_CODE_TOOL_MEMORY_CGROUP_EXCLUDE
What

On Linux and WSL, child processes started by Claude Code can now be placed into a memory-limited control group, so a runaway server or hook is killed at a cap instead of exhausting the host. This covers stdio MCP servers, LSP servers, hook runners, plugin installs, tmux agent sessions and the background terminal host, all launched through a wrapper that joins the capped group before running the real command. None of it is active in this build: the exclusion list falls back to a set containing every one of those classes, so the wiring is dark-launched unless CLAUDE_CODE_TOOL_MEMORY_CGROUP_EXCLUDE or server config says otherwise.

Details
  • The two shared process-spawning helpers now accept useToolMemoryCgroup and toolCgroupClass options, and plugin subprocesses pass the plugin class.
  • A process started before the cgroup is ready has its process id parked and is adopted into the group once the group exists, rather than being lost track of.
  • MCP capping has its own switch, CLAUDE_CODE_MCP_MEMORY_CGROUP or failing that the tengu_mcp_memory_cgroup setting; only an explicit false opts out, and when it resolves to disabled MCP is added to the exclusion list and no MCP server is capped.
  • Each MCP server process is registered against the cgroup by process id together with its start time read from /proc, rechecked whenever the set of hooks changes, so a stale process id cannot be mistaken for a live server.
  • A capped MCP server is released from the cap just before a hook backed by that server fires, so the hook does not run against a constrained process; a fixed set of events skips this release path, including Notification, SessionStart, SessionEnd, Setup and StopFailure.
  • Claude Code's own helpers deliberately opt out with useToolMemoryCgroup: !1: npm update checks, the Linux clipboard helpers, the CA installer, AWS credential export, systemctl, xdg-open and "open project in IDE".
  • The external editor launch and the terminal host retry the spawn without the cgroup if the first attempt fails.
  • When an LSP server dies by SIGKILL or exit 137 while capped, the crash message names the cause by appending killed at the tool memory limit (CLAUDE_CODE_TOOL_MEMORY_LIMIT), or says "likely killed" when it cannot confirm the cause.
  • If the host has too little memory for the default cap, the feature disables itself and logs tool cgroup: disabled (host too small for the default cap); the tool cgroup: log lines are all new in this build.
Evidence

{ echo 0 > "$0"/cgroup.procs; } 2>/dev/null; exec "$@", toolCgroupClass, useToolMemoryCgroup: !1, useToolMemoryCgroup, tool cgroup: disabled (host too small for the default cap), killed at the tool memory limit (CLAUDE_CODE_TOOL_MEMORY_LIMIT), hook was still capped at fire time, let { useToolMemoryCgroup: r, toolCgroupClass: o, ...i } = n,

Strings lifted out of the shipped bundle, so the claim above can be checked against them.

Related

Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.

See this entry in the whole of v2.1.246 →