Codex.app GUI: MCP child processes not reaped after task completion — 1300+ zombies, 37GB memory leak

What version of Codex CLI is running?

codex-cli 0.98.0 (Codex.app GUI wrapper)

What subscription do you have?

ChatGPT Pro

Which model were you using?

o3 (via Codex.app GUI)

What platform is your computer?

macOS 26.3 (25D125), Apple M4 Max, 64GB RAM, arm64

What issue are you seeing?

Codex.app spawns codex exec --full-auto worker processes for each worktree but never reaps them or their MCP child processes when tasks complete. Over multiple audit sessions, this accumulated 1,319 zombie Codex processes and 1,537 node processes consuming ~37GB RSS + 40GB swap on a 64GB machine, causing severe system-wide slowdown.

Root cause analysis

Each Codex.app task creates:

1× codex exec --full-auto --skip-git-repo-check --json - (CLI worker)
4× oh-my-codex MCP servers (state, memory, trace, code-intel)
1× Serena MCP server (via uv tool uvx)
1× uv process for Serena

≈ 7 processes per task. None are killed when the task completes.

With 12 git worktrees created by Codex.app (detached HEAD, pointing at old commits), this produced:

12 worktrees × ~110 child processes = ~1,320 sleeping processes
Combined RSS: ~37GB (mostly npm/node/uv MCP servers)
Swap usage: 39.4GB (on 64GB physical RAM)

When Codex.app (PID 19947) was killed, 2 additional codex exec workers (launched Friday and Saturday) were reparented to launchd (PPID=1), confirming they were never properly cleaned up.

Process tree snapshot (before cleanup)

Codex.app (PID 19947, 279MB)
├── codex exec --full-auto (PID 19970, 123MB)
│   └── 880× node/npm/uv children (27GB total)
│       ├── npm (236MB each, ×2)
│       ├── npm (140MB each, ×4)
│       ├── uv (91MB each, ×2)
│       └── node (77MB each, ×dozens)
├── Codex Helper Renderer (PID 20018, 602MB)
└── Codex Helper (PID 19971, 101MB)

Orphaned (PPID=1, reparented from dead Codex.app sessions):
├── codex exec --full-auto (PID 59326, Fri 23:59)
│   ├── oh-my-codex/state-server.js
│   ├── oh-my-codex/memory-server.js
│   ├── oh-my-codex/trace-server.js
│   ├── oh-my-codex/code-intel-server.js
│   └── serena start-mcp-server
└── codex exec --full-auto (PID 59747, Sat 22:05)
    └── (same MCP stack)

Memory impact

Metric	Before cleanup	After cleanup	Delta
Swap used	39.4 GB	8.0 GB	-31 GB
Codex processes	1,319	0	-100%
Node processes	1,537	17	-99%
Free pages	82K	2.3M	×28

Worktree state at time of discovery

All 12 worktrees were detached HEAD on old commits (2+ phases behind current main), confirming tasks had completed long ago:

/Users/drg/.codex/worktrees/0585/medical-ai  627d44e (detached HEAD)
/Users/drg/.codex/worktrees/0b7b/medical-ai  627d44e (detached HEAD)
/Users/drg/.codex/worktrees/2a60/medical-ai  4d53e7d (detached HEAD)
... (12 total, all on 2 old commits)

Current HEAD: 71aefff — none of the worktrees were anywhere near current.

What steps can reproduce the bug?

Use Codex.app GUI to run multiple tasks on a git repository (especially with MCP servers configured via oh-my-codex)
Let tasks complete normally
Wait a few hours / run more tasks
Check process count: ps aux | grep -c codex
Check memory: ps aux | grep codex | awk '{sum+=$6} END {printf "%.0f MB\n", sum/1024}'

Accumulation is proportional to number of tasks × MCP servers configured.

What is the expected behavior?

When a Codex.app task completes:

The codex exec worker process should be terminated
All MCP child processes (oh-my-codex servers, Serena, uv) should be killed via process group signal
The git worktree should be cleaned up if the task is done (or at minimum, child processes should not persist)

What is the actual behavior?

Worker processes and their entire MCP subtree remain alive indefinitely
No cleanup occurs on task completion, app quit, or even app crash (reparented to launchd)
Memory grows unboundedly with each task

Relationship to existing issues

CLI-494 (fixed, Oct 2025): start_kill() without wait() in exec.rs — same root cause pattern (missing process reaping), but fix only covered timeout/Ctrl+C in CLI, not GUI lifecycle
CLI-3017 (Jan 2026): CLI memory leak causing crashes
#12414 (Feb 2026, open): Unbounded memory growth when idle on v0.104.0

This issue is distinct because it specifically affects Codex.app GUI and its interaction with MCP server child processes — the GUI spawns long-lived codex exec workers that themselves spawn MCP servers, creating a deeper process tree that the existing cleanup logic does not handle.

Suggested fix

Process group kill: codex exec workers should use setsid() / process groups so all children (MCP servers) can be killed with a single killpg() on task completion
Worktree lifecycle: Codex.app should track active worktrees and clean up stale ones on startup (e.g., remove worktrees whose tasks are no longer active)
Heartbeat/watchdog: MCP servers spawned by codex exec should monitor their parent and self-terminate if the parent dies (check PPID periodically, or use a pipe/fd that breaks on parent death)

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

MCP servers eat up memory when multi-tasking in Codex App #11324
Add automatic lifecycle cleanup for completed/idle sub-agents (and unused MCP clients) #12335
Codex CLI multi-agent spawns duplicate Serena MCP instances instead of sharing one connection #12333
Codex App UI freezes: worker crashes, massive git/worktree errors, and concurrent orphaned app-server processes #11090

Powered by Codex Action

I put up a draft fix for this path: #12505

Scope is intentionally narrow and low-risk:

adds features.thread_listener_cleanup as an experimental flag (default off)
clears per-thread listener state when subscriber count drops to zero (when flag is enabled)
always clears app-server thread state during archive teardown
avoids event serialization work when there are no subscribers

I am currently seeing memory pressure in app usage with 5+ concurrent threads, so this is aimed at reducing retained in-memory thread/listener state without changing default behavior.

Given the updated contribution policy (invitation-only PRs), #12505 is currently a draft patch proposal to make discussion concrete. If this direction aligns with maintainer intent, would someone from the team be willing to explicitly invite that PR (or suggest a narrower scope)? I can provide additional repro/profiling details from macOS sessions where memory pressure climbs with 5+ concurrent threads.

Experiencing this on Linux / codex-cli 0.106.0

Reproducing the same issue. Here's a breakdown of the two distinct leak patterns I'm seeing:

Environment:

codex-cli 0.106.0
Ubuntu 25.10, Linux 6.17.0-14-generic x86_64

Crash: failed to spawn thread: Os { code: 11, kind: WouldBlock, message: "Resource temporarily unavailable" }

Two distinct leak patterns observed:

Zombie children not reaped (missing waitpid): A single long-running codex session accumulated 41 zombie <defunct> children — all from a Python stdio MCP server. The MCP server forks subprocesses for tool calls, but the codex parent never calls waitpid() to reap them. pstree output:
```
codex,49983
  |-(MainThread,105811) <defunct>
  |-(MainThread,125138) <defunct>
  |-(MainThread,131433) <defunct>
  ... (41 total zombies)
```
MCP server processes not terminated on session exit: When a codex session ends or is interrupted, its stdio MCP child processes are never sent SIGTERM. They persist indefinitely. I found 8 separate MCP process trees (one per stale codex session), each still running. These are live processes consuming real resources, not just zombies.

The combination of both leaks led to thread exhaustion and the crash. This appears to be the same root cause as #4726 (closed) and #6201 (closed) — neither of which fully resolved the lifecycle management for stdio MCP servers.

I can confirm a very similar issue on macOS, and I captured a full CLI process snapshot on March 11, 2026.

Environment

Codex App version: 26.305.950
macOS: 14.3.1 (23D60)
Usage pattern: multiple Codex App projects/threads open over time
MCPs in use: context7, stripe, playwright

What I observed

The machine was not in a peak CPU spike at the exact time of capture, but memory pressure was already high:
- 607 total processes
- 5760 threads
- 15G used, 74M unused
- 6608M compressor
- 6342612 swapins
- 8519545 swapouts
The most important part is the process tree under a single Codex desktop app-server PID:
- codex app-server PID 60306
- direct children of PID 60306: 73
- of those, 72 were MCP launchers
- exact breakdown:
  - 24 x npm exec @upstash/context7-mcp
  - 24 x npm exec @stripe/mcp --tools=all
  - 24 x npm exec @playwright/mcp@latest
- including descendants, that subtree contained 148 processes total

This does not look like a bounded “currently active work only” baseline. It looks like repeated MCP launcher accumulation over time under the same long-lived codex app-server.

Long-lived duplicated MCP launcher examples

about 8h old:
- npm exec @playwright/mcp@latest
- npm exec @stripe/mcp --tools=all
- npm exec @upstash/context7-mcp
about 4h old:
- another full trio of playwright / stripe / context7
about 3h old:
- more repeated trios
about 1h old:
- more repeated trios
about 50m old:
- more repeated trios
about 20h+ old:
- more repeated trios still attached to the same app-server

Important distinction

I understand from #12333 that duplicate MCP instances may be expected while subagents/threads are active.
What seems wrong here is lifecycle / teardown:
- the desktop app is not converging back to a small stable baseline
- stale MCP launchers keep accumulating under the same codex app-server PID over many hours

This feels closely related to:

#12491
#11324
#12976
possibly the earlier stdio MCP cleanup work in #10710

Question for maintainers

Should the process-group cleanup merged in #10710 have covered this desktop app path as well?
Or is there still a separate cleanup gap in the desktop app / app-server lifecycle?

Thanks for taking a look. The snapshot seems to point to unbounded MCP process accumulation over time rather than short-lived fanout from currently active work, so hopefully it helps narrow the cleanup path.

This looks related to #11324, but I wanted to add a narrower app-server angle that may help isolate root cause.

I traced a reproducible case where the leaking MCP children are not orphaned from dead workers; instead they remain attached to the long-lived desktop codex app-server process after conversations are no longer active.

The key detail from source review is that MCP servers are conversation-scoped and the intended unload path is thread/unsubscribe. When the last subscriber unsubscribes, the app-server shuts down the thread and unloads it. However, on connection removal the current app-server code path retains zero-subscriber threads instead of unloading them, so their McpConnectionManagers never drop and the stdio MCP child processes stay alive.

I posted the fuller write-up and evidence here:

#11324 comment: MCP servers eat up memory when multi-tasking in Codex App #11324 (comment)

So this may be the same family of leak as this issue, but specifically through desktop thread lifecycle / unload behavior rather than only worker reaping.

fix(mcp): reap superseded MCP connection managers on refresh

Analysis (community)

Thanks for tracking this — attempting a residual-focused analysis aligned with docs/contributing.md (invitation-only: analysis in-thread, no unsolicited PR).

Issue under review: Codex.app GUI: MCP child processes not reaped after task completion — 1300+ zombies, 37GB memory leak #12491 — Codex.app GUI: MCP child processes not reaped after task completion — 1300+ zombies, 37GB memory leak
Theme / radar cluster: MCP/helper processes not reaped (process-leak)
Reporter posture: static + local evidence where available; not claiming a maintainer invite.

Observed (from issue + public residual signal)

Codex.app GUI: MCP child processes not reaped after task completion — 1300+ zombies, 37GB memory leak ## What version of Codex CLI is running? codex-cli 0.98.0 (Codex.app GUI wrapper) ## What subscription do you have? ChatGPT Pro ## Which model were you using? o3 (via Codex.app GUI) ## What platform is your computer? macOS 26.3 (25D125), Apple M4 Max, 64GB RAM, arm64 ## What issue are you seeing? Codex.app spawns `codex exec --full-auto` worker processes for each worktree but never reaps t

Root-cause hypothesis

MCP/Node helper processes retained after task completion (GUI path especially) accumulate CPU/RAM; aligns with desktop OOM reports.

High-level fix outline (not a PR)

Explicit process group + wait/reap on task end and session close.
Cap concurrent helper children; surface unreaped count in diagnostics.
Fail-first: spawn mock MCP, complete task, assert zero orphan children.

Questions for maintainers

Is the intended long-term policy documented for this area (especially sandbox gitdir / log TRACE defaults)?
Preferred residual anchor issue if several open threads describe the same mechanism?
If the high-level outline above is roughly aligned, would an invited PR with failing-first tests be welcome later — or is an internal fix preferred?

Happy to refine with more measurements or code pointers. No unsolicited PR from me.

Analysis (community)

Residual analysis for #12491 (GUI: MCP child processes not reaped) — invitation-only. Long-open process-lifecycle residual; distinct from Windows WMI/taskkill mega-threads (not pile-on of denylisted storms). No unsolicited PR.

Deterministic evidence (code)

Code (5dd992acd3):

Test helper documents the fragility of process cleanup: codex-rs/mcp-server/tests/common/mcp_process.rs
- uses tokio::process::Child with .kill_on_drop(true) (≈L82)
- comments note kill_on_drop is not a guarantee (≈L39–L41, ≈L360)
Production MCP orchestration centers on codex-rs/codex-mcp connection manager (connection_manager / rmcp_client re-exports) — lifecycle of external Node/stdio MCP servers must be joined on task end and session close.
Local TRACE shows ongoing MCP manager activity: codex_mcp::connection_manager ≈1745 TRACE rows under codex-cli 0.146.0-alpha.6 sessions on this host (indirect signal of frequent connect/disconnect churn).

Root-cause hypothesis

Task completion / GUI session teardown does not always wait on MCP child process groups. kill_on_drop in tests acknowledges cleanup is best-effort; production paths that spawn helpers without a guaranteed join accumulate orphans → RAM/CPU growth over long Desktop sessions (adjacent symptoms on #33582 / #32797, different platforms).

High-level fix outline (not a PR)

Process-group spawn + guaranteed wait on task end, thread close, and app-server shutdown.
Cap concurrent MCP helper batches; surface unreaped-child count in doctor/diagnostics.
Prefer one long-lived MCP connection manager over per-turn respawn where protocol allows.
Fail-first: mock MCP server child; complete task; assert zero orphan PIDs (and that kill_on_drop is not the only line of defense).

Questions for maintainers

Is reaping owned by app-server, desktop shell, or codex-mcp connection manager?
Preferred test location for process-lifecycle (suite vs mcp-server tests)?
Would an invited PR for join-on-complete + diagnostics be useful?

No unsolicited PR from me.

Title:ChatGPT macOS app leaks zombie (defunct) child processes — exhausts
per-user process limit

App version: ChatGPT 26.730.61639 (Codex Framework 151.0.7922.71)
OS: macOS 14 (Darwin 23.2.0), Apple Silicon

Description:
The ChatGPT desktop app continuously accumulates (zombie) child
processes without reaping them. The parent is the main ChatGPT process, and
the leak traces to the embedded Codex app-server / code-mode-host chain
(codex app-server → node_repl / codex-code-mode-host).

Rate: ~36 zombies/minute. After ~10 minutes of runtime the app held 400+
zombie processes.

Impact: On macOS the per-user process limit (kern.maxprocperuid) is 2666. At
this leak rate the app exhausts the process table in roughly an hour, after
which the entire system fails to fork new processes — every shell and app
throws fork failed: resource temporarily unavailable until ChatGPT is quit.
Quitting ChatGPT lets launchd reap all zombies instantly, confirming the app
is the sole cause.

Root cause (likely): child processes are fork()ed but the parent never calls
wait()/waitpid() to reap them.

Steps to reproduce:

Launch ChatGPT desktop and leave it running (idle is enough; the
code-mode/agent host spawns subprocesses).
Run ps -eo ppid,stat | awk '$2==<ChatGPT_PID> && $3 ~ /Z/' | wc -l
periodically.
Observe the zombie count climb steadily and never drop.

Expected: child processes are reaped; zombie count stays near zero.
Actual: zombies grow unbounded until the OS process limit is hit.

@yanxiaolong01

@yanxiaolong01's process chain narrows the ownership question I raised above: codex app-server → node_repl / codex-code-mode-host is the code-mode host spawn path, not the stdio MCP server path that codex-mcp's connection manager owns. ~36 zombies/min with the parent still alive means the children exit and are never wait()ed — a missing reap on the host side, not a kill/teardown ordering bug.

Two things that would make this actionable:

@yanxiaolong01: ps -o pid,ppid,stat,command -p <zombie-pid> for a handful of the defunct entries, plus the PPID chain. Whichever process is the direct parent owns the wait(), and that decides where the fix goes.
Maintainers: same question as before, now scoped — does the code-mode host reap its node_repl children explicitly, or does it rely on drop-time kill the way the test helper does (codex-rs/mcp-server/tests/common/mcp_process.rs, .kill_on_drop(true) ≈L82, with the "not a guarantee" comment at ≈L39-41)?

Fail-first test unchanged: spawn a code-mode cell, complete the task, assert zero defunct children under the app-server PID. No unsolicited PR from me.

Requested ps data (ChatGPT 26.730.61639 / Codex Framework 151.0.7922.71,

macOS 14.2 23C64, Apple Silicon)

Ran the scoped ps you asked for. The direct parent of the zombies is NOT
the app-server — it's the top-level native host process.

Zombie sample (ps -axo pid,ppid,stat,command):
71372 70992 Z
71442 70992 Z
71445 70992 Z

PPID chain:
<zombie 71372> Z --PPID--> 70992 --PPID--> 1 (launchd)
70992 S /Applications/ChatGPT.app/Contents/MacOS/ChatGPT # top-level
native host, PPID=1
71348 S /Applications/ChatGPT.app/Contents/Resources/codex -c
features.code_mode_host=true app-server --analytics-default-enabled #
PPID=70992

Zombie parent distribution (own zombies only):
949 70992 <- ChatGPT top-level native host (the leak)
19 1506 <- Google Chrome (unrelated 3rd party)
3 70835 <- GoogleUpdater (unrelated 3rd party)

Key finding that scopes the fix:

codex ... code_mode_host=true app-server (PID 71348) currently has
zero child processes — it is not the direct parent of any defunct.
All code-mode defunct children reparent to / are owned by the top-level
ChatGPT native host (70992), whose PPID=1.
So the missing wait() lives in the top-level host that actually spawns the
code-mode node children, not inside the app-server / MCP
connection-manager layer.

Rate: 70992-owned zombies went 972 → 981 in 15s (~36/min), parent stays in
state S (alive) the whole time — confirms a pure missing-reap, not a
kill/teardown-ordering bug.

Windows evidence: the leaked children are NOT orphans, and lifetime CPU cannot identify them

Adding a Windows data point that differs from most of the thread in two ways that I think are actionable. Cross-references #22992 (duplicate MCP servers across conversations) and #30753 (duplicate pools after RefreshMcpServers), which describe the same shape.

Environment

Windows 11 Pro 25H2, build 26200.8973, 63.7 GiB RAM
Codex Desktop OpenAI.Codex_26.730.8199.0_x64
codex.exe ... app-server --analytics-default-enabled, launched by ChatGPT.exe
16 stdio MCP servers declared in config.toml
Claude Code also running on the same host, which gives a useful control group

1. Every leaked process had a LIVE agent ancestor

I walked the full ancestry of all 605 MCP/language-server processes rather than checking the direct parent. All 605 resolved to a live claude.exe or codex.exe ancestor. Zero were orphaned.

A parent-is-dead check finds nothing here, which is why this can look like "no leak" to tooling that only looks one level up. The processes are attached to a live app-server and simply never serve again.

Attribution by owning root:

root	direct children	shape
`claude.exe` #79308	16	exactly one of each server
`claude.exe` #43492	21	~one of each
`claude.exe` #38668	19	~one of each
`codex.exe` #81384	213	59 node, 42 graphify, 28 serena, 28 cocoindex, 13 vault-semantic, …

Totals: codex #81384 owned 454 of the 605. The three Claude Code sessions owned 40–60 each.

2. Spawn timeline: complete fleets, repeatedly, never reaped

33 processes = one full fleet of my 16 servers. Creation timestamps for codex #81384's direct children:

09:39  ###################  19
09:40  ################     16
09:42  ################     16
10:19  ############################################################  63
10:32  ################################  32
10:38  ################  16
10:40  #########################  25
10:41  #########################  25

Roughly 13 fleets in about an hour. No previous fleet was terminated.

3. The discriminator: lifetime CPU is useless, windowed CPU is not

This is the part I have not seen stated in the thread, and it matters for anyone writing cleanup logic.

Several of my servers load an ML model at startup. Each vault-semantic instance burns 9–13 s of CPU importing torch and loading BGE-M3 before it ever listens. So a "has it done work?" test based on lifetime CPU classifies 7.5 GiB idle duplicates as busy and keeps them.

Sampling CPU over a live window instead is blind to startup cost:

668 of 669 MCP processes consumed ZERO CPU over a 25-second window

Example of the two figures disagreeing on the same process:

vault-semantic pid=48224  lifetimeCpu=13.4 s  windowCpu=0 s  age=48 min  priv=7493 MiB

4. Cost

147 GiB of commit charge held by instances beyond the first per (root, server)
Host reached 95.1 % commit (243 GiB / 255.7 GiB), 3.7 GiB available
Windows logged 5 × Resource Exhaustion (Event ID 2004), naming vmmemWSL and two python.exe at 7.86 GiB each

Terminating all-but-newest per (root, server), restricted to processes idle over a live window, reclaimed 93.9 GiB and took commit from 95 % to 42 %. Nothing broke: the newest instance under each root is the one the session is actually using.

5. Suggestion

Whatever the eventual fix (#20883's project-scoped pool would remove the class entirely), a teardown heuristic that keys on liveness of the parent will not catch this, and one that keys on lifetime CPU will keep the most expensive offenders. Keying on "newest instance per (owning agent, server)" plus a windowed idleness check identified 499 of 669 processes correctly here with no false positives.

Happy to provide the raw per-process table or re-run any specific measurement.

Environment

macOS: 14.2 (Sonoma)
ChatGPT Version: 26.803.41515 (Build 6321)

Verification

Tested on the latest version (26.803.41515) with real-time
monitoring:

Total processes: Stable at 12-13
Zombie processes: 0
Process state distribution: All in S (sleeping) or R (running) state

Conclusion

Issue Resolved: Version 26.803.41515 no longer exhibits
the zombie subprocess accumulation issue.

This thread conflates several different problems. That makes it difficult to tell which of these have been fixed and which still exist. I can say with high confidence that the original bug reported in this thread was fixed, which is why I initially closed the issue. It looks like it was reopened at some point because similar symptoms were reported. There is at least one other bug related to ProcessHandle::terminate() that is a real bug, and I'll work on a fix for that one.

If you are seeing other bugs that involve process leaks, please open a new issue and provide details so we can track it independently.

@etraut-openai

Thanks @etraut-openai — agreed this thread conflated several process-lifecycle failures.

My earlier residual notes were aimed at that same split (owned-process reaping / ProcessHandle::terminate() vs the original Desktop zombie report). Standing down here; will only open a new issue if I can reproduce a distinct residual with a clean repro.

The ProcessHandle::terminate() issue will be addressed in the next release, so I'm going to close this. As I mentioned above, if you see similar symptoms, please open a new bug report. Thanks!

@etraut-openai

Thanks @etraut-openai — appreciated the split clarification and the upcoming ProcessHandle::terminate() fix. Standing by for the next release; will only open a fresh issue if a distinct residual shows up with a clean repro.

One pattern I saw: leftover helpers from an older app instance (cua_node/bin/node … kernel.js) have CODEX_SANDBOX set but no thread id, their parent is launchd and their group leader is gone. Those three together are a pretty safe way to spot them. Just checking "parent is launchd" flags hundreds of normal processes on macOS.

I put this in a read-only tool if it helps: https://github.com/berkkorkmaz/tidewake

Codex.app GUI: MCP child processes not reaped after task completion — 1300+ zombies, 37GB memory leak #12491

Description

Codex.app GUI: MCP child processes not reaped after task completion — 1300+ zombies, 37GB memory leak

What version of Codex CLI is running?

What subscription do you have?

Which model were you using?

What platform is your computer?

What issue are you seeing?

Root cause analysis

Process tree snapshot (before cleanup)

Memory impact

Worktree state at time of discovery

What steps can reproduce the bug?

What is the expected behavior?

What is the actual behavior?

Relationship to existing issues

Suggested fix

Activity

github-actions commented on Feb 22, 2026

vincentkoc commented on Feb 22, 2026

vincentkoc commented on Feb 22, 2026

gabrielbryk commented on Mar 1, 2026

masvelio commented on Mar 11, 2026

RemarkRemedy commented on Mar 16, 2026

39 remaining items

bbingz commented on Jul 24, 2026

Analysis (community)

Observed (from issue + public residual signal)

Root-cause hypothesis

High-level fix outline (not a PR)

Related

Questions for maintainers

bbingz commented on Jul 24, 2026

Analysis (community)

Deterministic evidence (code)

Root-cause hypothesis

High-level fix outline (not a PR)

Questions for maintainers

yanxiaolong01 commented on Aug 5, 2026

bbingz commented on Aug 6, 2026

yanxiaolong01 commented on Aug 6, 2026

Requested ps data (ChatGPT 26.730.61639 / Codex Framework 151.0.7922.71,

hoklims commented on Aug 6, 2026

Windows evidence: the leaked children are NOT orphans, and lifetime CPU cannot identify them

1. Every leaked process had a LIVE agent ancestor

2. Spawn timeline: complete fleets, repeatedly, never reaped

3. The discriminator: lifetime CPU is useless, windowed CPU is not

4. Cost

5. Suggestion

yanxiaolong01 commented on Aug 7, 2026

Environment

Verification

Conclusion

etraut-openai commented on Aug 7, 2026

bbingz commented on Aug 7, 2026

etraut-openai commented on Aug 7, 2026

bbingz commented on Aug 7, 2026

berkkorkmaz commented on Oct 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions