Follow Discord
Sweep 22 Oct 2026 · 21:04Z Build v2.1.309 528 read Stable v2.1.308 Latest v2.1.309 Next v2.1.309 Feeds RSS JSON llms.txt llms-full.txt Unofficial

Claude Code v2.1.246 ·

Tool subprocesses can be launched inside a memory-capped cgroup

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

Nothing to try yet Notable No documentation found In Development
JSON All of v2.1.246
Nothing to try yetTier: how much it should matter to you
3Useful: my rating, 1 to 5
4Signal: worth watching, 1 to 5
SandboxArea: what it touches
In DevelopmentKind: in v2.1.246,
What probably matters to youSection of the release

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.

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.

Read from
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

What has happened since
Flag reading moved The flag server now returns off for tengu_mcp_memory_cgroup, read as this account. A reading is one sample. Claude Code evaluates its flags remotely, so no client sees the targeting rule behind a value and this says nothing about your account.
Flag reading moved The flag server now returns nothing at all, having stopped carrying it for tengu_mcp_memory_cgroup, read as this account. A reading is one sample. Claude Code evaluates its flags remotely, so no client sees the targeting rule behind a value and this says nothing about your account.

See this across every release →

How sure we are
One source agreesOne thing we can check says the same as this entry.
The name it cites is new in this buildNew in this build: CLAUDE_CODE_TOOL_MEMORY_CGROUP_EXCLUDE

See this entry in the whole of v2.1.246 →

Feedback