My Mac mini (24GB) hard-froze with an OOM yesterday and I traced it back to the ChatGPT desktop app's codex host.
Every codex conversation in the app spawns a fresh copy of every stdio MCP server from ~/.codex/config.toml (playwright, context7, github, shadcn, exa, firecrawl, node_repl...) and nothing ever reaps them when the conversation ends. The parent codex app-server stays alive, so they aren't orphans either — they just pile up until the machine falls over.
Numbers from yesterday, ~10 hours after a clean reboot:
codex app-server subtree: 545 processes, 28.0 GB total footprint (measured with footprint -a)- 282 node processes: ~36 copies each of exa-mcp-server, firecrawl-mcp, shadcn mcp, context7-mcp, playwright-mcp, mcp-server-github
- swap 12.3/13 GB full on a 24 GB machine, then the OOM freeze
Environment:
- macOS 26 (Darwin 25.4.0), Apple Silicon, 24 GB
- ChatGPT desktop 150.0.7871.115, app-server launched with
-c features.code_mode_host=true
- ~8 stdio MCP servers in config.toml — any of them reproduce it
Looks like the same family as #28361 (Windows CLI path), #25015 (Linux subagents), #26773 / #26869 — filing separately because none of those cover the macOS desktop app, and this confirms the bug is cross-platform rather than windows-os. Same signature as #28361 too: one-shot codex exec cleans up its children fine, the persistent app-server path never does.
Current workaround is a launchd job that restarts the whole app once the subtree passes ~120 processes, which works but is not exactly a fix.
My Mac mini (24GB) hard-froze with an OOM yesterday and I traced it back to the ChatGPT desktop app's codex host.
Every codex conversation in the app spawns a fresh copy of every stdio MCP server from
~/.codex/config.toml(playwright, context7, github, shadcn, exa, firecrawl, node_repl...) and nothing ever reaps them when the conversation ends. The parentcodex app-serverstays alive, so they aren't orphans either — they just pile up until the machine falls over.Numbers from yesterday, ~10 hours after a clean reboot:
codex app-serversubtree: 545 processes, 28.0 GB total footprint (measured withfootprint -a)Environment:
-c features.code_mode_host=trueLooks like the same family as #28361 (Windows CLI path), #25015 (Linux subagents), #26773 / #26869 — filing separately because none of those cover the macOS desktop app, and this confirms the bug is cross-platform rather than windows-os. Same signature as #28361 too: one-shot
codex execcleans up its children fine, the persistent app-server path never does.Current workaround is a launchd job that restarts the whole app once the subtree passes ~120 processes, which works but is not exactly a fix.