### Preflight Checklist - [x] I searched existing issues and found related memory/startup reports, but not this specific failure mode. - [x] This is a single bug report. - [x] I am using the latest Claude Code version available to me. ### Suggested Labels The issue is already tagged with `bug`, `has repro`, `platform:macos`, `perf:memory`, and `area:agents`. Additional labels that match the evidence, if maintainers can apply them: - `terminal` - `perf:cpu` - `area:agent-sdk` - `area:plugins

[BUG] Startup launches many headless sdk-cli sessions in Ghostty, causing macOS memory pressure/freeze (v2.1.126)

Resolved 💬 1 comment Opened May 3, 2026 by ZenAlexa Closed Jun 1, 2026

Preflight Checklist

[x] I searched existing issues and found related memory/startup reports, but not this specific failure mode.
[x] This is a single bug report.
[x] I am using the latest Claude Code version available to me.

Suggested Labels

The issue is already tagged with bug, has repro, platform:macos, perf:memory, and area:agents.

Additional labels that match the evidence, if maintainers can apply them:

terminal
perf:cpu
area:agent-sdk
area:plugins
area:hooks
area:cli

I would avoid area:mcp as the primary tag: MCP appears to amplify the storm after each child session starts, but the first cause appears to be the headless sdk-cli session burst.

What's Wrong?

Starting Claude Code in Ghostty can cause a rapid CPU/memory spike that makes macOS unresponsive. Local evidence points to a startup/session storm of non-interactive sdk-cli Claude Code processes, not a single interactive TUI process.

The strongest signal is Claude Code telemetry around the freeze: within seconds, multiple tengu_started / tengu_init events appear with:

entrypoint=sdk-cli
client_type=sdk-cli
is_interactive=false
terminal=ghostty
version=2.1.126
is_running_with_bun=true
node_version=v24.3.0

The same telemetry reports tengu_concurrent_sessions reaching 24 concurrent sessions. Each process was roughly 200-330 MB RSS, and some had high CPU usage. This lines up with macOS system logs showing VM-compressor memory pressure and jetsam events.

Environment

Claude Code: 2.1.126
Claude Code build time from telemetry: 2026-04-30T16:01:00Z
OS: macOS 26.4, Darwin 25.4.0, arm64
Terminal: Ghostty 1.3.1 stable
Telemetry terminal value: ghostty
Runtime from telemetry: Bun-backed Claude Code process, node_version=v24.3.0

Relevant Claude global settings:

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1",
    "NODE_ENV": "production",
    "DISABLE_AUTOUPDATER": "1"
  },
  "teammateMode": "in-process",
  "effortLevel": "high",
  "autoCompactEnabled": false,
  "skipAutoPermissionPrompt": true
}

Other local context:

Enabled plugins include agent-sdk-dev, superpowers, document-skills, frontend-design, code-review, pr-review-toolkit, swift-lsp, typescript-lsp, episodic-memory, telegram, figma, and others.
Many MCP servers are configured. claude mcp list currently checks 23 servers.
~/.claude/teams/default/inboxes/*.json contained old unread agent-team messages from April.
Ghostty config has window-save-state = always, but no evidence that Ghostty itself auto-runs claude.
Shell startup files define Claude aliases and env vars, but I found no shell startup command that auto-launches Claude Code.

Evidence

1. macOS memory pressure before shutdown/reboot

Local time 2026-05-03 21:42:54:

kernel: memorystatus: killing due to "vm-compressor-space-shortage"
launchd: exited with exit reason ... JETSAM_REASON_MEMORY_VMCOMPRESSOR_SPACE_SHORTAGE

This repeated for many system processes. I did not find a clean panic log proving a kernel panic; this looks like severe memory pressure causing process kills and then user/system shutdown or reboot.

2. Claude telemetry: concurrent non-interactive sessions

Selected sanitized rows from tengu_concurrent_sessions:

timestamp_utc              entrypoint  interactive  terminal  version  num_sessions  rss_bytes  cpu_percent
2026-05-03T13:48:03.830Z  sdk-cli     false        ghostty   2.1.126  2             331988992  60.01
2026-05-03T13:48:04.832Z  sdk-cli     false        ghostty   2.1.126  10            330612736  30.04
2026-05-03T13:48:05.166Z  sdk-cli     false        ghostty   2.1.126  14            322912256  93.99
2026-05-03T13:48:06.487Z  sdk-cli     false        ghostty   2.1.126  18            323239936  4.76
2026-05-03T13:48:18.368Z  sdk-cli     false        ghostty   2.1.126  24            294256640  31.75
2026-05-03T14:38:57.865Z  sdk-cli     false        ghostty   2.1.126  16            218415104  13.94
2026-05-03T14:39:05.239Z  sdk-cli     false        ghostty   2.1.126  18            209240064  4.91
2026-05-03T14:40:30.932Z  sdk-cli     false        ghostty   2.1.126  22            102465536  67.30

There are many nearby telemetry events for:

tengu_started
tengu_init
tengu_cli_flags
tengu_exit
tengu_run_hook
tengu_headless_plugin_install
tengu_hook_plugin_injected
tengu_skill_loaded
tengu_claudeai_mcp_eligibility
tengu_mcp_server_connection_succeeded
tengu_mcp_server_connection_failed
tengu_mcp_tools_listed

3. Independent session files created in a burst

In one later burst, ~/.claude/sessions/*.json showed 10 independent sdk-cli session files created within about 2.5 minutes:

2026-05-03 22:38:00 +0800  pid 37371  cwd ~/Developer/GitHub/OLo
2026-05-03 22:38:01 +0800  pid 38400  cwd ~/Developer/GitHub/OLo
2026-05-03 22:38:06 +0800  pid 38982  cwd ~/Developer/GitHub/OLo
2026-05-03 22:38:37 +0800  pid 42535  cwd ~
2026-05-03 22:38:37 +0800  pid 47284  cwd ~
2026-05-03 22:38:38 +0800  pid 46982  cwd ~
2026-05-03 22:38:40 +0800  pid 47808  cwd ~
2026-05-03 22:38:57 +0800  pid 49341  cwd ~
2026-05-03 22:39:03 +0800  pid 50639  cwd ~
2026-05-03 22:40:30 +0800  pid 51078  cwd ~

Each file has entrypoint: "sdk-cli".

Why I don't think MCP is the root cause

MCP likely amplifies the blast radius, but it does not look like the first cause.

The bad state is already visible as many non-interactive sdk-cli Claude Code sessions. Each child session then appears to perform MCP eligibility checks, MCP connection/list-tools work, plugin injection, hook execution, and skill loading. With 16-24 child sessions, those startup costs multiply quickly.

So the likely root is whichever Claude Code subsystem starts or rehydrates these headless sdk-cli sessions during startup, resume, plugin install/check, agent teams, or SDK/plugin workflows. MCP is one of the expensive things each spawned session does afterward.

Current root-cause hypotheses

My best current hypothesis:

CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 plus teammateMode=in-process is causing agent-team or SDK work to be rehydrated on startup.
Old unread ~/.claude/teams/**/inboxes/*.json messages may be treated as pending work and trigger multiple headless sdk-cli sessions.
Each headless session loads plugins, hooks, skills, and MCP tools independently.
With many enabled plugins and 23 MCP servers, the per-session cost becomes large enough that 16-24 concurrent sessions exhaust CPU and memory.

Other possible contributors:

agent-sdk-dev plugin may be involved, since telemetry consistently identifies entrypoint=sdk-cli / client_type=sdk-cli.
tengu_headless_plugin_install appears during the later burst, so plugin install/sync/check code may be another trigger.
Ghostty window-save-state = always could multiply the issue if it restores multiple tabs/windows, but I found no evidence that Ghostty itself is auto-launching claude.
Status line and hooks add overhead, but they do not explain the creation of many independent sdk-cli sessions.
autoCompactEnabled=false and high output-token settings may worsen memory use during normal sessions, but they do not explain a startup storm by themselves.

Expected Behavior

Starting one interactive Claude Code instance should not spawn an unbounded or large number of non-interactive sdk-cli sessions.

If agent teams, plugin checks, MCP checks, or SDK subprocesses are required, Claude Code should enforce a strict concurrency/resource cap and should not rehydrate stale agent-team inboxes without explicit user action.

Actual Behavior

Starting Claude Code can create many non-interactive sdk-cli sessions in seconds. The combined resource usage pushes macOS into VM-compressor-space-shortage jetsam, making the machine unresponsive.

Related Issues I Found

https://github.com/anthropics/claude-code/issues/47248 - memory leak on macOS ARM64
https://github.com/anthropics/claude-code/issues/51077 - memory leak after startup in VS Code integrated terminal
https://github.com/anthropics/claude-code/issues/4953 - large memory leak/OOM report
https://github.com/anthropics/claude-code/issues/17711 - CLI degrades over time

I am filing this separately because the distinctive failure mode here is the documented sdk-cli concurrent-session burst during startup in Ghostty.

Requested Maintainer Help

Could you check which subsystem is responsible for spawning these headless sdk-cli sessions?

In particular:

Agent teams / teammateMode=in-process
Rehydration of stale ~/.claude/teams/**/inboxes/*.json
agent-sdk-dev or SDK CLI orchestration
Headless plugin install/sync/check path
Per-child-session MCP initialization

It would also help if Claude Code emitted a visible warning or refused to continue when tengu_concurrent_sessions crosses a low threshold, because the current failure mode can freeze the whole OS before the user can intervene.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗