You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
macOS ChatGPT desktop: app-server leaks a full MCP server stack per conversation (545 procs / 28 GB in ~10h) #32339
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.
Closing as a duplicate of #30408. This is the same persistent app-server per-conversation MCP process accumulation on macOS, with a severe memory/swap impact. The 545-process snapshot here is useful corroboration, and #30408 remains the place to track which thread lifecycle boundaries fail to release the processes.
Activity
github-actions commentedon Jul 11, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
etraut-openai commentedon Oct 13, 2026
(response from codex)
Closing as a duplicate of #30408. This is the same persistent app-server per-conversation MCP process accumulation on macOS, with a severe memory/swap impact. The 545-process snapshot here is useful corroboration, and #30408 remains the place to track which thread lifecycle boundaries fail to release the processes.