Codex Desktop should use a project-scoped MCP process pool instead of starting MCP per session

Codex Desktop currently appears to start stdio MCP servers per loaded chat/session instead of sharing them per project/workspace.

Observed behavior:

Opening the first chat in a project starts MCP server processes.
Opening another existing chat in the same project can start another MCP process group or restart the previous one.
Creating a new chat inside the same project can also start a new MCP process group.
Projectless/non-project chats may start MCP servers too.
This is easy to observe with Serena because it creates serena.exe, but it also affects other stdio MCP servers such as servers launched through npx or uvx.

Expected behavior:

MCP servers should be scoped to the normalized project/workspace root.
All chats/sessions/subagents in the same project should reuse one shared MCP pool.
Switching between chats in the same project should not kill or restart MCP servers.
Creating a new chat in an already loaded project should attach to the existing project MCP pool.
Projectless chats should not start project-scoped MCP servers.

Suggested fix:

Move MCP ownership from individual sessions to the app-server/thread-manager level.
Keep a shared MCP pool keyed by normalized project/workspace root, not by chat/session id.
Treat projectless chats as mcp_project_root = None, so MCP is disabled for them.
Initialize MCP once per project pool and reuse it for all sessions/subagents in that project.
Do not refresh/recreate the MCP manager during every session initialization; only refresh on explicit MCP reload/config changes.

I also prototyped a local proof-of-concept patch that fixes this behavior on my machine.

The patch changes MCP ownership from per-session to an app-server/thread-manager-level shared pool:

ThreadManager owns a shared MCP pool.
Sessions receive mcp_project_root: Option<PathBuf>.
None disables MCP for projectless chats.
Some(project_root) attaches the session to a project-scoped MCP pool.
The pool is keyed by normalized codex_home + project_root.
Session startup uses initialize-once semantics instead of recreating MCP on every session load.
Explicit MCP reload can still force-refresh the pool.

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

Conditionally start MCP servers based on project #20494
fix: stdio MCP child process leak causing unbounded memory growth #19469
Codex desktop repeatedly spawns duplicate STDIO MCP server processes and leaves them running #19845
Codex Desktop leaks MCP server processes from internal title-generation sessions on Windows #19858
Codex Desktop accumulates duplicate MCP/helper process trees and multi-GB RSS during UI/debugging workflows #20349

Powered by Codex Action

@etraut-openai

@etraut-openai please do not close this as a duplicate. So here I'm not talking about the problem, but about its solution.

Also, it may seem to me, but it's like useless memory leaks have gone away, which clogged my swap file from 15gb to 55gb:(

Same here

Please fix

Additional Windows data point from Codex Desktop 26.506.3741.0.

I also submitted in-app feedback with correlation ID:

8e832ac8-8641-4794-9005-cdd1ce9d3812

Observed before reboot in one long-lived Codex Desktop session on Windows:

Codex app-server PID: 8900
Package: OpenAI.Codex_26.506.3741.0_x64
Platform: Windows 11

Duplicated MCP/helper process families under the same app-server:
- ue-mcp actual servers:        46  (~3.4 GB working set)
- xcodebuildmcp actual servers: 40  (~3.5 GB working set)
- hzos-dev-mcp.exe:             50  (~1.0 GB working set)
- node_repl.exe:                45  (~0.8 GB working set)
- ue/xcode wrapper processes:  259  (~7.0 GB working set)
- claude mcp serve:              4  (~0.5 GB working set)
- gemini-cli MCP:                2  (~0.15 GB working set)

Important detail: these were mostly not Windows-orphaned processes. They remained direct or descendant children of the live codex.exe app-server, so killing/restarting Codex/Windows cleaned them up. The issue looked like logical lifecycle leakage: new thread/subagent/tool contexts started fresh MCP/helper stacks while previous ones stayed alive.

Subagents made the symptom visibly worse. Starting several subagents caused new instances of hzos-dev-mcp, node_repl, ue-mcp, xcodebuildmcp, plus claude/gemini MCP processes to appear in the same app-server envelope.

Relevant local log signals from %USERPROFILE%\.codex\logs_2.sqlite:

RunningService dropped without explicit close(): 2414 occurrences
failed to initialize MCP client during shutdown: 108 occurrences
MCP startup failed: timed out handshaking: 79 occurrences

Examples included shutdown paths like:

RunningService dropped without explicit close(). The connection will be closed asynchronously. For guaranteed cleanup, call close() or cancel() before dropping.
failed to initialize MCP client during shutdown: MCP startup failed: timed out handshaking with MCP server after 30s/60s/120s

After a full Windows reboot and disabling/removing the previous explicit MCP starters, the massive ue-mcp/xcodebuildmcp/hzos-dev-mcp buildup was gone. Browser Use is still enabled and node_repl.exe instances are present, but currently bounded compared to the pre-reboot state.

This seems consistent with the issue title here: MCP/helper processes are scoped too narrowly to sessions/subagents/tool contexts, or old session-scoped managers are not explicitly closed/cancelled. A project/app-server-scoped pool plus explicit teardown on session/subagent shutdown would likely address this class of leak.

Related issues I found while triaging: #17574, #17832, #18881, #20349, #20867, #20980.

I put together a focused draft patch branch for this class of issue:

https://github.com/openai/codex/compare/main...mySebbe:codex:mysebbe/defer-subagent-mcp-startup?expand=1

Scope:

adds a lazy MCP startup mode so forked/subagent sessions can construct an MCP manager without immediately polling every enabled stdio client
passes an inherited MCP tool snapshot from the live parent thread into forks/subagents
uses that snapshot for model-visible MCP tool inventory, code-mode nested tools, app instructions, and MCP tool-name resolution
keeps eager startup for root sessions, explicit refresh/status/resource paths, and required MCP servers
skips shutdown polling for lazy clients that were never started

I tried to open this as a draft PR, but both gh pr create and the GitHub connector were blocked for this account/integration (CreatePullRequest / Resource not accessible by integration). Local verification was limited to git diff --check; this Windows test machine does not have cargo/rustc installed, so it still needs CI/maintainer validation.

Additional narrower Windows node_repl.exe data point from Codex Desktop 26.506.3741.0.

This confirms the behavior is coming from the installed Desktop app, not from a local source checkout or custom build:

Codex.exe PID 6448
  path: C:\Program Files\WindowsApps\OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0\app\Codex.exe
codex.exe app-server PID 8536
  path: C:\Program Files\WindowsApps\OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0\app\resources\codex.exe

Current observation after a reboot and normal Codex/subagent usage:

node_repl.exe children under app-server PID 8536: 34
combined working set: ~639 MB
all node_repl.exe command lines:
  C:\Users\sebbe\AppData\Local\OpenAI\Codex\bin\node_repl.exe

Only one of those node_repl.exe processes currently has an actual Node kernel child:

node_repl.exe PID 13420
  child node.exe PID 10220
  node.exe --experimental-vm-modules ...\kernel.js --session-id 9aa94c3d7b7941e4bf89821d45e67b14

So the leak shape is mostly idle/stale node_repl.exe MCP host processes, not many active JS kernels.

The process creation times correlate with Codex thread/subagent starts from state_5.sqlite. Closing diagnostic subagents emitted fresh shutdown log entries like:

rmcp::service: RunningService dropped without explicit close().
The connection will be closed asynchronously. For guaranteed cleanup, call close() or cancel() before dropping.

After those subagents closed, the corresponding node_repl.exe count did not return to baseline. In this local run it moved from 32 to 34 during the investigation, which makes this a useful black-box repro for the teardown side of the issue.

Important distinction: there is a local patch branch experimenting with lazy MCP startup for forked/subagent sessions, but the observed live processes are all parented by the installed Windows app-server above. The earliest observed stale node_repl.exe in this session also predates that local patch commit, so this is not caused by the local patch.

Related issue with the eager-start side of the same lifecycle problem: #21984.

Maintainer handoff for the draft patch branch, since GitHub currently rejects opening a PR from my fork with:

mySebbe does not have the correct permissions to execute CreatePullRequest

The branch is still available and fetchable:

git fetch https://github.com/mySebbe/codex.git mysebbe/defer-subagent-mcp-startup:mysebbe/defer-subagent-mcp-startup
git switch mysebbe/defer-subagent-mcp-startup

Commit:

c00e26d Defer MCP startup for forked sessions

Compare view:

https://github.com/openai/codex/compare/main...mySebbe:codex:mysebbe/defer-subagent-mcp-startup?expand=1

Patch intent:

add McpStartupMode::{Eager, Lazy}
keep root sessions / required MCP servers / explicit refreshes eager
let forked/subagent sessions inherit the parent MCP tool snapshot when possible
use that snapshot for tool inventory and tool-name resolution
avoid starting and then shutting down unused stdio MCP clients for subagents/forks

This is not meant as the full project-scoped MCP process pool from the issue title. It is a smaller mitigation for the observed duplicate-process amplification caused by subagents/forks and tool inventory startup. Maintainer review would be especially useful around Desktop/app-server lifecycle assumptions and whether the inherited snapshot should be invalidated in more cases.

Linux headless `app-server` data point (OpenClaw gateway)

Confirming this affects the headless codex app-server --listen stdio:// path on Linux, not just Desktop.

Environment:

Ubuntu 24.04, 8 GB RAM VPS
@openai/codex-linux-x64 via OpenClaw gateway (Telegram bot → Codex app-server)
11 MCP servers configured (gmail, google-calendar, gbrain, n8n, github, filesystem, youtube-transcript, fetch, time, hermes-tools, lazyweb)

Observed behavior:
After ~5 minutes of normal Telegram bot usage, the single codex app-server process (PID 2829) had spawned 3 complete generations of MCP server processes — 33 direct children total.

Generation 1 (elapsed 04:07): 11 MCP processes, ~891 MB RSS
Generation 2 (elapsed 03:52): 11 MCP processes, ~884 MB RSS  
Generation 3 (elapsed 03:35): 11 MCP processes, ~823 MB RSS (active)
Total under codex app-server: 2,598 MB RSS (33 children)

Each generation includes a full duplicate set: google-calendar-mcp (155 MB each), gmail-mcp (118 MB), hermes-tools-mcp (118 MB), n8n mcp-remote (108 MB), gbrain serve (94 MB), etc. Plus 3 Docker containers for n8n-mcp (one per generation).

This caused swap thrashing (kswapd0 pinned at top CPU) and triggered the hosting provider's automated CPU throttling.

Workaround: systemctl restart of the parent service clears all leaked generations. We've added MemoryMax=2G in systemd and a cron-based periodic restart as a safety net until this is fixed upstream.

The project-scoped MCP pool proposed here would completely resolve this for the headless app-server use case as well.

@etraut-openai

@etraut-openai When will the problem be fixed?

Additional current-build evidence supporting shared or project-scoped MCP ownership is in #32797.

On Windows package 26.707.8479.0, one Desktop app-server retained three distinct MCP/Node batches totaling 83 node.exe, 3 node_repl.exe, and 54 cmd.exe wrappers. Most configured MCP tools had not been deliberately invoked in the visible task. The three process batches remained simultaneously live and consumed about 7.74 GiB working set.

The desired behavior is not to make tools unavailable. It is to preserve automatic tool availability while reusing one bounded pool, lazily starting server processes when supported, and reliably terminating superseded session/manager pools.

I reproduced this on macOS arm64 with Codex App 26.707.72221 / bundled codex-cli 0.144.2, and narrowed the long-lived growth to subscribed-thread lifecycle rather than the MCP server implementations themselves.

Production-profile snapshot:

18 loaded rollouts
141 direct children under the live app-server
about 13.2 GB RSS across the Codex process tree before deeper descendant accounting
nearly one full node_repl + five plugin MCP servers + xcodebuildmcp group per loaded thread

Controlled test using the same prompt and binary in an isolated profile:

lean configuration: 4 processes / 128.9 MB RSS
same task with six MCP servers: 11 processes / 799.4 MB RSS
incremental cost: about 670 MB per loaded task
five Node plugin servers: 320.3 MB
xcode MCP launcher + child: 309.2 MB
app-server/core + sleep: 169.9 MB

In tag rust-v0.144.2, codex-rs/app-server/src/request_processors/thread_lifecycle.rs only schedules the existing 30-minute idle unload when a thread is inactive and has zero subscribers. The Desktop app appears to keep background/sidebar threads subscribed, so that condition never becomes true; the per-thread McpConnectionManager therefore remains alive and its children do not drop.

I tested an experimental, opt-in backend safety valve that permits subscribed-but-idle thread eviction after a separately configured timeout. It is disabled by default, so existing behavior is unchanged unless explicitly enabled. Four focused Rust unit tests passed.

End-to-end App Server test with a real persisted turn, an active subscription, and the six-server stack:

before idle eviction: 9 processes / 819 MB RSS
after 5 idle seconds: 1 process / 171 MB RSS; MCP helpers gone and thread/loaded/list empty
resume of the same persisted thread: succeeded; tools/helpers restored, 9 processes / 835 MB RSS

This preserved thread history and tool capability while releasing the idle MCP processes. My read is that the preferred product fix is for Desktop to unsubscribe background threads correctly, with a backend subscribed-idle eviction policy as defense in depth. Renderer retention appears to be a separate issue.

can someone do a PR fix for this?

Additional Windows data point from Codex Desktop 26.715.10079.0, bundled CLI 0.145.0-alpha.30.

The configuration was already mitigated:

ambient suggestions disabled
no automatic subagents
six suitable MCP servers migrated from local wrappers to Streamable HTTP
local stdio MCP integrations preserved

With five active Desktop tasks, the app-server accumulated:

158 node.exe
95 cmd.exe
56 powershell.exe
309 processes total
approximately 27.2 GB combined working set

Four tasks were then explicitly completed and became idle, but the process and memory counts did not decrease. The MCP process trees remained attached to the live Desktop app-server, so this was logical lifecycle retention rather than ordinary Windows-orphaned processes.

After manually reaping only the recognized MCP trees belonging to the completed tasks, the total dropped to approximately 2 GB. A subsequent test with four conversations active simultaneously remained bounded at 32–37 helper/shell processes and 1.94–2.22 GB for several minutes, without another complete MCP generation appearing.

This does not prove that the current app implements a shared MCP pool. It shows that remote HTTP servers, disabling invisible helper fan-out, and explicit teardown can mitigate the pressure. The durable fix still appears to be:

project/app-server-scoped MCP ownership;
reuse across conversations;
correct Desktop unsubscribe behavior;
explicit teardown of superseded or idle managers and their entire Windows process trees.

@etraut-openai

@etraut-openai When will the problem be fixed???

Additional controlled Windows Desktop observation of matching direct app-server Node-child growth after loading a terminal task.

Environment (operator-recorded; the attachments do not encode the package version)

OpenAI.Codex AppX: 26.730.8199.0
Windows Desktop

Post-restart baseline A1

The experiment record says the app was restarted normally and only the current task was reopened. The attached artifacts begin after that restart.
Four samples during a 20.9-second monitor run.
Official ChatGPT/Codex tree: 18-20 processes, 2,122.0-2,176.8 MiB private.
One app-server: 140.0-179.2 MiB private.
One direct Node child under that app-server: 74.5 MiB private.
Three renderers: 632.4 MiB private in the final sample.

Operator-recorded action between A1 and A2

I viewed one terminal older task and returned to the original task without sending a prompt, Steer, Queue, approval, or resume request.
The attachments do not contain UI-input telemetry or a timestamp for that action.

Timestamp partition

Two matching direct app-server Node children started at 04:07:36.964 UTC and 04:07:43.664 UTC.
A separate diagnostic subagent was not created until 04:08:04.492 UTC, so those two children cannot be attributed to that subagent.
The subagent creation was followed 0.414858 seconds later by a third matching child; that later event is reported separately in [Windows App 26.707.9981.0] MCP suites persist after subagents complete, reaching 10.9 GB private memory #33531.

A2

Four samples during a 20.8-second monitor run.
Official tree: 24-26 processes, 2,689.0-2,728.6 MiB private.
The same single app-server: 346.9-376.4 MiB private.
Four matching direct Node children total: 299.2-299.3 MiB private.
Three renderers: 730.5 MiB private in the final sample.

Conservative interpretation

Association of the two pre-subagent children with the task-view/return interval relies on the operator-recorded experiment sequence; the artifacts are not continuous UI or ETW traces.
I am not claiming that one child is a complete MCP suite, that process ownership is proven, that the entire A2 delta came from task switching, or that one cycle proves an unbounded leak.
The measured result is matching app-server child growth that did not return to the A1 baseline during the observation window.

Expected behavior / diagnostic request

Viewing a terminal task without interaction should not retain additional matching app-server child runtimes.
Diagnostics should expose thread/agent -> MCP manager/process ownership and any scheduled teardown deadline.

Collection used read-only process and task-state inspection. The attachments contain process relationships, timestamps, memory aggregates, and sanitized identity hashes rather than raw paths or command lines. The event-correlation JSON was assembled after A2 and explicitly is not a continuous ETW trace.

Sanitized supporting data:

A1 post-restart aggregate JSONL — SHA-256 703e1d0374def087bb93e3c4bf115130ffb3cb7711a92b4fcec8fd9afb888961

{"kind":"monitor_start","schemaVersion":2,"timestampUtc":"2026-08-06T04:04:11.4790136Z","intervalSeconds":5,"durationSeconds":20,"scriptHash":"10cc80fa7b4be901bf8936e21b80d55555cb1f6c7d88e7346787c1232057e6d4","outputPathHash":"55f579e30eb0226602d01c2afcf2b4b149e5f65bcdee84a7ef5008aec82c2af1","launchIdentity":{"pid":33256,"ppid":33196,"startedUtc":"2026-08-06T04:04:10.6184720Z","sessionId":1,"exePathHash":"656870b7a837ffb1e8c22c3dc5bfb387c113804399f06d16fa6a7a1dba65bb4d","commandHash":"b0bc06891966db72f0bd01b59835e2b6528b0a1a8f366f31cf0f8d8e0937cad5"}}
{"kind":"sample","timestampUtc":"2026-08-06T04:04:12.1174912Z","sampleElapsedMs":616.1,"system":{"totalVisibleMiB":32511.8,"freePhysicalMiB":17751.1},"trustedChatGptRootState":"matched","trustedChatGptRootCount":9,"unverifiedChatGptCount":0,"officialTree":{"count":20,"measured":20,"wsMiB":1918.8,"privateMiB":2122.0},"appServer":{"count":1,"measured":1,"wsMiB":199.1,"privateMiB":140.8},"appServerNodeDescendants":{"count":1,"measured":1,"wsMiB":64.5,"privateMiB":74.5},"chatGptRoles":[{"pid":35488,"ppid":17772,"startedUtc":"2026-08-06T03:59:23.7772030Z","role":"official-chatgpt-browser","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":308.0,"privateMiB":987.9},{"pid":21308,"ppid":29704,"startedUtc":"2026-08-06T03:59:23.9574340Z","role":"official-chatgpt-crashpad-handler","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":12.1,"privateMiB":2.7},{"pid":29704,"ppid":35488,"startedUtc":"2026-08-06T03:59:23.9116990Z","role":"official-chatgpt-crashpad-handler","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":13.9,"privateMiB":3.1},{"pid":16592,"ppid":35488,"startedUtc":"2026-08-06T03:59:25.2380010Z","role":"official-chatgpt-gpu-process","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":177.3,"privateMiB":143.4},{"pid":17196,"ppid":35488,"startedUtc":"2026-08-06T03:59:30.4036010Z","role":"official-chatgpt-renderer","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":230.5,"privateMiB":175.4},{"pid":29968,"ppid":35488,"startedUtc":"2026-08-06T03:59:30.4020010Z","role":"official-chatgpt-renderer","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":509.0,"privateMiB":436.1},{"pid":39704,"ppid":35488,"startedUtc":"2026-08-06T03:59:32.6287540Z","role":"official-chatgpt-renderer","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":36.0,"privateMiB":21.7},{"pid":1448,"ppid":35488,"startedUtc":"2026-08-06T03:59:25.2507260Z","role":"official-chatgpt-utility","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":43.4,"privateMiB":16.7},{"pid":27068,"ppid":35488,"startedUtc":"2026-08-06T03:59:25.2787970Z","role":"official-chatgpt-utility","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":25.6,"privateMiB":15.5}],"trackedDetachedCodex":{"state":"not-configured","root":null,"tree":{"count":0,"measured":0,"wsMiB":0.0,"privateMiB":0.0},"nodeDescendants":{"count":0,"measured":0,"wsMiB":0.0,"privateMiB":0.0}},"trackedOpenCodexBun":{"state":"matched","root":{"pid":36340,"ppid":5616,"startedUtc":"2026-08-05T23:50:00.1820700Z","role":"tracked-opencodex-bun","exePathHash":"b392d68acc767031e25418b2fb56379f1fa8f00ab7fa37fbdff0f1e658597804","wsMiB":276.5,"privateMiB":723.9},"tree":{"count":1,"measured":1,"wsMiB":276.5,"privateMiB":723.9},"nodeDescendants":{"count":0,"measured":0,"wsMiB":0.0,"privateMiB":0.0}},"monitor":{"pid":33256,"wsMiB":107.5,"privateMiB":40.2}}
{"kind":"sample","timestampUtc":"2026-08-06T04:04:17.5880285Z","sampleElapsedMs":439.9,"system":{"totalVisibleMiB":32511.8,"freePhysicalMiB":17726.7},"trustedChatGptRootState":"matched","trustedChatGptRootCount":9,"unverifiedChatGptCount":0,"officialTree":{"count":20,"measured":20,"wsMiB":1943.8,"privateMiB":2142.1},"appServer":{"count":1,"measured":1,"wsMiB":198.4,"privateMiB":140.0},"appServerNodeDescendants":{"count":1,"measured":1,"wsMiB":64.5,"privateMiB":74.5},"chatGptRoles":[{"pid":35488,"ppid":17772,"startedUtc":"2026-08-06T03:59:23.7772030Z","role":"official-chatgpt-browser","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":308.3,"privateMiB":988.3},{"pid":21308,"ppid":29704,"startedUtc":"2026-08-06T03:59:23.9574340Z","role":"official-chatgpt-crashpad-handler","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":12.1,"privateMiB":2.7},{"pid":29704,"ppid":35488,"startedUtc":"2026-08-06T03:59:23.9116990Z","role":"official-chatgpt-crashpad-handler","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":13.9,"privateMiB":3.1},{"pid":16592,"ppid":35488,"startedUtc":"2026-08-06T03:59:25.2380010Z","role":"official-chatgpt-gpu-process","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":184.9,"privateMiB":151.4},{"pid":17196,"ppid":35488,"startedUtc":"2026-08-06T03:59:30.4036010Z","role":"official-chatgpt-renderer","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":233.2,"privateMiB":178.3},{"pid":29968,"ppid":35488,"startedUtc":"2026-08-06T03:59:30.4020010Z","role":"official-chatgpt-renderer","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":509.1,"privateMiB":436.2},{"pid":39704,"ppid":35488,"startedUtc":"2026-08-06T03:59:32.6287540Z","role":"official-chatgpt-renderer","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":36.0,"privateMiB":21.7},{"pid":1448,"ppid":35488,"startedUtc":"2026-08-06T03:59:25.2507260Z","role":"official-chatgpt-utility","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":43.6,"privateMiB":16.8},{"pid":27068,"ppid":35488,"startedUtc":"2026-08-06T03:59:25.2787970Z","role":"official-chatgpt-utility","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":25.5,"privateMiB":15.5}],"trackedDetachedCodex":{"state":"not-configured","root":null,"tree":{"count":0,"measured":0,"wsMiB":0.0,"privateMiB":0.0},"nodeDescendants":{"count":0,"measured":0,"wsMiB":0.0,"privateMiB":0.0}},"trackedOpenCodexBun":{"state":"matched","root":{"pid":36340,"ppid":5616,"startedUtc":"2026-08-05T23:50:00.1820700Z","role":"tracked-opencodex-bun","exePathHash":"b392d68acc767031e25418b2fb56379f1fa8f00ab7fa37fbdff0f1e658597804","wsMiB":276.1,"privateMiB":720.2},"tree":{"count":1,"measured":1,"wsMiB":276.1,"privateMiB":720.2},"nodeDescendants":{"count":0,"measured":0,"wsMiB":0.0,"privateMiB":0.0}},"monitor":{"pid":33256,"wsMiB":122.5,"privateMiB":49.6}}
{"kind":"sample","timestampUtc":"2026-08-06T04:04:23.0148840Z","sampleElapsedMs":412.2,"system":{"totalVisibleMiB":32511.8,"freePhysicalMiB":17686.1},"trustedChatGptRootState":"matched","trustedChatGptRootCount":9,"unverifiedChatGptCount":0,"officialTree":{"count":20,"measured":20,"wsMiB":1979.1,"privateMiB":2176.8},"appServer":{"count":1,"measured":1,"wsMiB":236.4,"privateMiB":179.2},"appServerNodeDescendants":{"count":1,"measured":1,"wsMiB":64.5,"privateMiB":74.5},"chatGptRoles":[{"pid":35488,"ppid":17772,"startedUtc":"2026-08-06T03:59:23.7772030Z","role":"official-chatgpt-browser","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":307.2,"privateMiB":987.0},{"pid":21308,"ppid":29704,"startedUtc":"2026-08-06T03:59:23.9574340Z","role":"official-chatgpt-crashpad-handler","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":12.1,"privateMiB":2.7},{"pid":29704,"ppid":35488,"startedUtc":"2026-08-06T03:59:23.9116990Z","role":"official-chatgpt-crashpad-handler","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":13.9,"privateMiB":3.1},{"pid":16592,"ppid":35488,"startedUtc":"2026-08-06T03:59:25.2380010Z","role":"official-chatgpt-gpu-process","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":180.6,"privateMiB":146.6},{"pid":17196,"ppid":35488,"startedUtc":"2026-08-06T03:59:30.4036010Z","role":"official-chatgpt-renderer","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":230.3,"privateMiB":175.2},{"pid":29968,"ppid":35488,"startedUtc":"2026-08-06T03:59:30.4020010Z","role":"official-chatgpt-renderer","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":509.4,"privateMiB":436.4},{"pid":39704,"ppid":35488,"startedUtc":"2026-08-06T03:59:32.6287540Z","role":"official-chatgpt-renderer","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":36.0,"privateMiB":21.7},{"pid":1448,"ppid":35488,"startedUtc":"2026-08-06T03:59:25.2507260Z","role":"official-chatgpt-utility","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":43.5,"privateMiB":16.7},{"pid":27068,"ppid":35488,"startedUtc":"2026-08-06T03:59:25.2787970Z","role":"official-chatgpt-utility","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":25.5,"privateMiB":15.5}],"trackedDetachedCodex":{"state":"not-configured","root":null,"tree":{"count":0,"measured":0,"wsMiB":0.0,"privateMiB":0.0},"nodeDescendants":{"count":0,"measured":0,"wsMiB":0.0,"privateMiB":0.0}},"trackedOpenCodexBun":{"state":"matched","root":{"pid":36340,"ppid":5616,"startedUtc":"2026-08-05T23:50:00.1820700Z","role":"tracked-opencodex-bun","exePathHash":"b392d68acc767031e25418b2fb56379f1fa8f00ab7fa37fbdff0f1e658597804","wsMiB":285.2,"privateMiB":738.6},"tree":{"count":3,"measured":3,"wsMiB":361.1,"privateMiB":788.8},"nodeDescendants":{"count":0,"measured":0,"wsMiB":0.0,"privateMiB":0.0}},"monitor":{"pid":33256,"wsMiB":128.5,"privateMiB":55.0}}
{"kind":"sample","timestampUtc":"2026-08-06T04:04:28.3622344Z","sampleElapsedMs":331.6,"system":{"totalVisibleMiB":32511.8,"freePhysicalMiB":17773.6},"trustedChatGptRootState":"matched","trustedChatGptRootCount":9,"unverifiedChatGptCount":0,"officialTree":{"count":18,"measured":18,"wsMiB":1945.7,"privateMiB":2156.1},"appServer":{"count":1,"measured":1,"wsMiB":223.1,"privateMiB":164.8},"appServerNodeDescendants":{"count":1,"measured":1,"wsMiB":64.5,"privateMiB":74.5},"chatGptRoles":[{"pid":35488,"ppid":17772,"startedUtc":"2026-08-06T03:59:23.7772030Z","role":"official-chatgpt-browser","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":307.9,"privateMiB":987.3},{"pid":21308,"ppid":29704,"startedUtc":"2026-08-06T03:59:23.9574340Z","role":"official-chatgpt-crashpad-handler","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":12.4,"privateMiB":2.8},{"pid":29704,"ppid":35488,"startedUtc":"2026-08-06T03:59:23.9116990Z","role":"official-chatgpt-crashpad-handler","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":14.2,"privateMiB":3.3},{"pid":16592,"ppid":35488,"startedUtc":"2026-08-06T03:59:25.2380010Z","role":"official-chatgpt-gpu-process","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":178.5,"privateMiB":144.4},{"pid":17196,"ppid":35488,"startedUtc":"2026-08-06T03:59:30.4036010Z","role":"official-chatgpt-renderer","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":230.3,"privateMiB":175.3},{"pid":29968,"ppid":35488,"startedUtc":"2026-08-06T03:59:30.4020010Z","role":"official-chatgpt-renderer","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":508.4,"privateMiB":435.4},{"pid":39704,"ppid":35488,"startedUtc":"2026-08-06T03:59:32.6287540Z","role":"official-chatgpt-renderer","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":36.0,"privateMiB":21.7},{"pid":1448,"ppid":35488,"startedUtc":"2026-08-06T03:59:25.2507260Z","role":"official-chatgpt-utility","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":43.6,"privateMiB":16.8},{"pid":27068,"ppid":35488,"startedUtc":"2026-08-06T03:59:25.2787970Z","role":"official-chatgpt-utility","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":25.7,"privateMiB":15.6}],"trackedDetachedCodex":{"state":"not-configured","root":null,"tree":{"count":0,"measured":0,"wsMiB":0.0,"privateMiB":0.0},"nodeDescendants":{"count":0,"measured":0,"wsMiB":0.0,"privateMiB":0.0}},"trackedOpenCodexBun":{"state":"matched","root":{"pid":36340,"ppid":5616,"startedUtc":"2026-08-05T23:50:00.1820700Z","role":"tracked-opencodex-bun","exePathHash":"b392d68acc767031e25418b2fb56379f1fa8f00ab7fa37fbdff0f1e658597804","wsMiB":279.6,"privateMiB":726.5},"tree":{"count":1,"measured":1,"wsMiB":279.6,"privateMiB":726.5},"nodeDescendants":{"count":0,"measured":0,"wsMiB":0.0,"privateMiB":0.0}},"monitor":{"pid":33256,"wsMiB":130.7,"privateMiB":56.8}}
{"kind":"monitor_end","timestampUtc":"2026-08-06T04:04:32.3757089Z","elapsedSeconds":20.9}

A2 partitioned aggregate JSONL — SHA-256 951c4c3c3656a8762e55f8dcddc0cced1c7b7079299a8f1cea23d397367d3c89

{"kind":"monitor_start","schemaVersion":2,"timestampUtc":"2026-08-06T04:12:21.8909822Z","intervalSeconds":5,"durationSeconds":20,"scriptHash":"10cc80fa7b4be901bf8936e21b80d55555cb1f6c7d88e7346787c1232057e6d4","outputPathHash":"8d8860f4a183afb6eb02b74a079c6a9c6dd536d4789eb738fc7ae73ca798e47f","launchIdentity":{"pid":41784,"ppid":33196,"startedUtc":"2026-08-06T04:12:21.0385660Z","sessionId":1,"exePathHash":"656870b7a837ffb1e8c22c3dc5bfb387c113804399f06d16fa6a7a1dba65bb4d","commandHash":"e76b105455b4a84c9d1427e44ce8da59491acba2804b6f57338f6f9342cfb318"}}
{"kind":"sample","timestampUtc":"2026-08-06T04:12:22.4158987Z","sampleElapsedMs":504.4,"system":{"totalVisibleMiB":32511.8,"freePhysicalMiB":17383.6},"trustedChatGptRootState":"matched","trustedChatGptRootCount":9,"unverifiedChatGptCount":0,"officialTree":{"count":26,"measured":26,"wsMiB":2473.1,"privateMiB":2689.0},"appServer":{"count":1,"measured":1,"wsMiB":411.4,"privateMiB":348.3},"appServerNodeDescendants":{"count":4,"measured":4,"wsMiB":257.6,"privateMiB":299.2},"chatGptRoles":[{"pid":35488,"ppid":17772,"startedUtc":"2026-08-06T03:59:23.7772030Z","role":"official-chatgpt-browser","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":325.0,"privateMiB":1005.7},{"pid":21308,"ppid":29704,"startedUtc":"2026-08-06T03:59:23.9574340Z","role":"official-chatgpt-crashpad-handler","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":12.3,"privateMiB":2.7},{"pid":29704,"ppid":35488,"startedUtc":"2026-08-06T03:59:23.9116990Z","role":"official-chatgpt-crashpad-handler","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":14.1,"privateMiB":3.1},{"pid":16592,"ppid":35488,"startedUtc":"2026-08-06T03:59:25.2380010Z","role":"official-chatgpt-gpu-process","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":183.2,"privateMiB":152.0},{"pid":17196,"ppid":35488,"startedUtc":"2026-08-06T03:59:30.4036010Z","role":"official-chatgpt-renderer","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":233.6,"privateMiB":177.5},{"pid":29968,"ppid":35488,"startedUtc":"2026-08-06T03:59:30.4020010Z","role":"official-chatgpt-renderer","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":596.1,"privateMiB":532.4},{"pid":31296,"ppid":35488,"startedUtc":"2026-08-06T04:08:03.2786300Z","role":"official-chatgpt-renderer","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":35.3,"privateMiB":20.2},{"pid":1448,"ppid":35488,"startedUtc":"2026-08-06T03:59:25.2507260Z","role":"official-chatgpt-utility","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":45.0,"privateMiB":17.3},{"pid":27068,"ppid":35488,"startedUtc":"2026-08-06T03:59:25.2787970Z","role":"official-chatgpt-utility","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":29.5,"privateMiB":18.9}],"trackedDetachedCodex":{"state":"not-configured","root":null,"tree":{"count":0,"measured":0,"wsMiB":0.0,"privateMiB":0.0},"nodeDescendants":{"count":0,"measured":0,"wsMiB":0.0,"privateMiB":0.0}},"trackedOpenCodexBun":{"state":"matched","root":{"pid":36340,"ppid":5616,"startedUtc":"2026-08-05T23:50:00.1820700Z","role":"tracked-opencodex-bun","exePathHash":"b392d68acc767031e25418b2fb56379f1fa8f00ab7fa37fbdff0f1e658597804","wsMiB":286.5,"privateMiB":743.8},"tree":{"count":1,"measured":1,"wsMiB":286.5,"privateMiB":743.8},"nodeDescendants":{"count":0,"measured":0,"wsMiB":0.0,"privateMiB":0.0}},"monitor":{"pid":41784,"wsMiB":107.4,"privateMiB":40.8}}
{"kind":"sample","timestampUtc":"2026-08-06T04:12:27.9369022Z","sampleElapsedMs":487.8,"system":{"totalVisibleMiB":32511.8,"freePhysicalMiB":17409.4},"trustedChatGptRootState":"matched","trustedChatGptRootCount":9,"unverifiedChatGptCount":0,"officialTree":{"count":24,"measured":24,"wsMiB":2466.7,"privateMiB":2694.0},"appServer":{"count":1,"measured":1,"wsMiB":410.0,"privateMiB":346.9},"appServerNodeDescendants":{"count":4,"measured":4,"wsMiB":257.6,"privateMiB":299.2},"chatGptRoles":[{"pid":35488,"ppid":17772,"startedUtc":"2026-08-06T03:59:23.7772030Z","role":"official-chatgpt-browser","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":324.2,"privateMiB":1005.0},{"pid":21308,"ppid":29704,"startedUtc":"2026-08-06T03:59:23.9574340Z","role":"official-chatgpt-crashpad-handler","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":12.3,"privateMiB":2.7},{"pid":29704,"ppid":35488,"startedUtc":"2026-08-06T03:59:23.9116990Z","role":"official-chatgpt-crashpad-handler","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":14.1,"privateMiB":3.1},{"pid":16592,"ppid":35488,"startedUtc":"2026-08-06T03:59:25.2380010Z","role":"official-chatgpt-gpu-process","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":183.9,"privateMiB":152.6},{"pid":17196,"ppid":35488,"startedUtc":"2026-08-06T03:59:30.4036010Z","role":"official-chatgpt-renderer","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":233.6,"privateMiB":177.5},{"pid":29968,"ppid":35488,"startedUtc":"2026-08-06T03:59:30.4020010Z","role":"official-chatgpt-renderer","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":595.2,"privateMiB":531.3},{"pid":31296,"ppid":35488,"startedUtc":"2026-08-06T04:08:03.2786300Z","role":"official-chatgpt-renderer","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":35.3,"privateMiB":20.2},{"pid":1448,"ppid":35488,"startedUtc":"2026-08-06T03:59:25.2507260Z","role":"official-chatgpt-utility","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":45.0,"privateMiB":17.2},{"pid":27068,"ppid":35488,"startedUtc":"2026-08-06T03:59:25.2787970Z","role":"official-chatgpt-utility","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":29.5,"privateMiB":18.9}],"trackedDetachedCodex":{"state":"not-configured","root":null,"tree":{"count":0,"measured":0,"wsMiB":0.0,"privateMiB":0.0},"nodeDescendants":{"count":0,"measured":0,"wsMiB":0.0,"privateMiB":0.0}},"trackedOpenCodexBun":{"state":"matched","root":{"pid":36340,"ppid":5616,"startedUtc":"2026-08-05T23:50:00.1820700Z","role":"tracked-opencodex-bun","exePathHash":"b392d68acc767031e25418b2fb56379f1fa8f00ab7fa37fbdff0f1e658597804","wsMiB":284.9,"privateMiB":735.6},"tree":{"count":1,"measured":1,"wsMiB":284.9,"privateMiB":735.6},"nodeDescendants":{"count":0,"measured":0,"wsMiB":0.0,"privateMiB":0.0}},"monitor":{"pid":41784,"wsMiB":122.0,"privateMiB":52.1}}
{"kind":"sample","timestampUtc":"2026-08-06T04:12:33.3820083Z","sampleElapsedMs":426.7,"system":{"totalVisibleMiB":32511.8,"freePhysicalMiB":17358.2},"trustedChatGptRootState":"matched","trustedChatGptRootCount":9,"unverifiedChatGptCount":0,"officialTree":{"count":24,"measured":24,"wsMiB":2503.1,"privateMiB":2728.6},"appServer":{"count":1,"measured":1,"wsMiB":438.7,"privateMiB":376.4},"appServerNodeDescendants":{"count":4,"measured":4,"wsMiB":257.6,"privateMiB":299.2},"chatGptRoles":[{"pid":35488,"ppid":17772,"startedUtc":"2026-08-06T03:59:23.7772030Z","role":"official-chatgpt-browser","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":324.5,"privateMiB":1005.4},{"pid":21308,"ppid":29704,"startedUtc":"2026-08-06T03:59:23.9574340Z","role":"official-chatgpt-crashpad-handler","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":12.3,"privateMiB":2.7},{"pid":29704,"ppid":35488,"startedUtc":"2026-08-06T03:59:23.9116990Z","role":"official-chatgpt-crashpad-handler","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":14.1,"privateMiB":3.1},{"pid":16592,"ppid":35488,"startedUtc":"2026-08-06T03:59:25.2380010Z","role":"official-chatgpt-gpu-process","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":186.0,"privateMiB":154.8},{"pid":17196,"ppid":35488,"startedUtc":"2026-08-06T03:59:30.4036010Z","role":"official-chatgpt-renderer","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":233.5,"privateMiB":177.4},{"pid":29968,"ppid":35488,"startedUtc":"2026-08-06T03:59:30.4020010Z","role":"official-chatgpt-renderer","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":597.4,"privateMiB":533.4},{"pid":31296,"ppid":35488,"startedUtc":"2026-08-06T04:08:03.2786300Z","role":"official-chatgpt-renderer","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":35.3,"privateMiB":20.2},{"pid":1448,"ppid":35488,"startedUtc":"2026-08-06T03:59:25.2507260Z","role":"official-chatgpt-utility","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":45.0,"privateMiB":17.2},{"pid":27068,"ppid":35488,"startedUtc":"2026-08-06T03:59:25.2787970Z","role":"official-chatgpt-utility","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":29.5,"privateMiB":18.9}],"trackedDetachedCodex":{"state":"not-configured","root":null,"tree":{"count":0,"measured":0,"wsMiB":0.0,"privateMiB":0.0},"nodeDescendants":{"count":0,"measured":0,"wsMiB":0.0,"privateMiB":0.0}},"trackedOpenCodexBun":{"state":"matched","root":{"pid":36340,"ppid":5616,"startedUtc":"2026-08-05T23:50:00.1820700Z","role":"tracked-opencodex-bun","exePathHash":"b392d68acc767031e25418b2fb56379f1fa8f00ab7fa37fbdff0f1e658597804","wsMiB":297.7,"privateMiB":756.5},"tree":{"count":3,"measured":3,"wsMiB":372.5,"privateMiB":806.3},"nodeDescendants":{"count":0,"measured":0,"wsMiB":0.0,"privateMiB":0.0}},"monitor":{"pid":41784,"wsMiB":125.9,"privateMiB":53.6}}
{"kind":"sample","timestampUtc":"2026-08-06T04:12:38.7231491Z","sampleElapsedMs":330.1,"system":{"totalVisibleMiB":32511.8,"freePhysicalMiB":17400.3},"trustedChatGptRootState":"matched","trustedChatGptRootCount":9,"unverifiedChatGptCount":0,"officialTree":{"count":24,"measured":24,"wsMiB":2496.3,"privateMiB":2721.1},"appServer":{"count":1,"measured":1,"wsMiB":430.6,"privateMiB":367.5},"appServerNodeDescendants":{"count":4,"measured":4,"wsMiB":257.8,"privateMiB":299.3},"chatGptRoles":[{"pid":35488,"ppid":17772,"startedUtc":"2026-08-06T03:59:23.7772030Z","role":"official-chatgpt-browser","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":325.1,"privateMiB":1006.1},{"pid":21308,"ppid":29704,"startedUtc":"2026-08-06T03:59:23.9574340Z","role":"official-chatgpt-crashpad-handler","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":12.3,"privateMiB":2.7},{"pid":29704,"ppid":35488,"startedUtc":"2026-08-06T03:59:23.9116990Z","role":"official-chatgpt-crashpad-handler","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":14.1,"privateMiB":3.1},{"pid":16592,"ppid":35488,"startedUtc":"2026-08-06T03:59:25.2380010Z","role":"official-chatgpt-gpu-process","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":185.7,"privateMiB":154.4},{"pid":17196,"ppid":35488,"startedUtc":"2026-08-06T03:59:30.4036010Z","role":"official-chatgpt-renderer","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":233.8,"privateMiB":177.9},{"pid":29968,"ppid":35488,"startedUtc":"2026-08-06T03:59:30.4020010Z","role":"official-chatgpt-renderer","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":596.3,"privateMiB":532.4},{"pid":31296,"ppid":35488,"startedUtc":"2026-08-06T04:08:03.2786300Z","role":"official-chatgpt-renderer","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":35.3,"privateMiB":20.2},{"pid":1448,"ppid":35488,"startedUtc":"2026-08-06T03:59:25.2507260Z","role":"official-chatgpt-utility","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":45.0,"privateMiB":17.3},{"pid":27068,"ppid":35488,"startedUtc":"2026-08-06T03:59:25.2787970Z","role":"official-chatgpt-utility","exePathHash":"fc8fd08c96728a122347c94807a5624a6684dcd14e3aff969e0cbfc52b2f0d90","wsMiB":29.5,"privateMiB":18.9}],"trackedDetachedCodex":{"state":"not-configured","root":null,"tree":{"count":0,"measured":0,"wsMiB":0.0,"privateMiB":0.0},"nodeDescendants":{"count":0,"measured":0,"wsMiB":0.0,"privateMiB":0.0}},"trackedOpenCodexBun":{"state":"matched","root":{"pid":36340,"ppid":5616,"startedUtc":"2026-08-05T23:50:00.1820700Z","role":"tracked-opencodex-bun","exePathHash":"b392d68acc767031e25418b2fb56379f1fa8f00ab7fa37fbdff0f1e658597804","wsMiB":290.3,"privateMiB":747.2},"tree":{"count":1,"measured":1,"wsMiB":290.3,"privateMiB":747.2},"nodeDescendants":{"count":0,"measured":0,"wsMiB":0.0,"privateMiB":0.0}},"monitor":{"pid":41784,"wsMiB":127.3,"privateMiB":55.0}}
{"kind":"monitor_end","timestampUtc":"2026-08-06T04:12:42.7321369Z","elapsedSeconds":20.8}

Sanitized event-partition JSON — SHA-256 f2ed34a65e92db8dd6a0c78229f2c74a49d038d2b73355c73b1431bea235a5b8

@AIast0r

Hi @AIast0r, this subagent persistence/history issue aligns with some boundary anomalies observed in multi-agent rollouts. Codex Rescue Alpha5 provides read-only lifecycle and subagent boundary diagnostics, cleanly separating historical start markers from current live execution state without altering the source rollout.

If you have access to the local session, you can run a non-destructive check:

pip install codex-rescue==0.1.0a5
codex-rescue doctor --latest

No raw session data is required, and please redact private paths if you share any output.

Same failure on macOS with the Codex desktop app. Adding measurements in case concrete numbers help.

Version: codex-cli 0.150.0-alpha.8 (ChatGPT.app 26.820.60940), macOS arm64.

Shape: one long-lived codex mcp-server process; every conversation thread starts a fresh set of stdio MCP servers, and none are torn down when the thread ends.

75679  Claude.app/Contents/Helpers/disclaimer --pgroup --
 └ 75682  ChatGPT.app/.../codex mcp-server   (2h24m, 37 children)
   ├ haven-agentd-mcp   04:33
   ├ haven-agentd-mcp   03:24
   ├ haven-agentd-mcp   02:40
   ├ haven-agentd-mcp   02:18

After ~25 tool calls over about three hours: 12 haven-agentd-mcp and 12 haven-correspondence-mcp alive at once, same parent pid.

Why the children cannot help themselves. Both servers implement the normal stdio contract — while let line = readLine() { … }, which ends on EOF. They never get one. lsof on an abandoned child:

haven-age 1507 kjetil 0 PIPE 0xdddb15eaa365566a -> 0x6ba557a69b36ac89

fd 0 is still open against a pipe whose write end the parent holds, so read() blocks forever and the process sits in state S indefinitely. Closing the child stdin at thread teardown would be sufficient on its own — the servers would then exit unaided, with no other change needed.

Workaround, server side: an idle watchdog that exits when no MCP message has arrived for N minutes. It bounds the leak but does not remove it — every thread still pays for a full process start.

Windows data point from Codex Desktop `26.825.6671.0`: one stdio MCP process per thread, plus a second hidden thread per chat, all under one app-server

Environment

OS:                 Windows 11 Pro 25H2 (10.0.26200)
Codex Desktop:      OpenAI.Codex_26.825.6671.0_x64 (app_server.client_version="26.825.51511")
codex CLI core:     0.151.0-alpha.7.2 (from session_meta.cli_version)
app-server cmdline: codex.exe -c features.code_mode_host=true app-server ... (single PID 16600)
MCP server:         one stdio server, `ralhf-local` (our desktop app's MCP bridge, an Electron
                    binary run with ELECTRON_RUN_AS_NODE=1, ~100-130 MB working set each)

config.toml entry (paths trimmed):

[mcp_servers.ralhf-local]
command = 'C:\Users\<user>\AppData\Local\Programs\RaLHF\RaLHF.exe'
args = ['...\resources\app.asar.unpacked\dist\mcp-host.cjs']
[mcp_servers.ralhf-local.env]
ELECTRON_RUN_AS_NODE = "1"

Observed

Over one afternoon I opened 4 chats in the same project folder. That produced 8 ralhf-local processes, all direct children of the single codex.exe app-server PID. None were Windows orphans; they died when the parent told them to. Process creation times line up to the second with thread/start requests in %USERPROFILE%\.codex\logs_2.sqlite.

Each chat produced two threads and therefore two MCP process sets. The first is the visible chat (it has a rollout file under .codex/sessions/). The second is created 1-20 s later by another thread/start from Codex Desktop with thread_start.dynamic_tool_count=0, has no rollout file, and I never interacted with it. It still starts a full MCP set (ralhf-local and node_repl).

Visible chat `thread/start`	ralhf PID	Hidden 2nd thread	ralhf PID	Hidden thread shut down
13:49:56 `01a06134-0eb5…`	42160 (still alive)	13:49:57 `01a06134-1288…`	43284	14:20:03
13:59:58 `01a0613d-3b9e…`	37076 (still alive)	14:00:17 `01a0613d-87ba…`	36256	14:30:20
14:02:11 `01a0613f-44c6…`	32400 (still alive)	14:02:19 `01a0613f-657c…`	9164	14:32:22
14:10:31 `01a06146-e667…`	37748 (still alive)	14:10:40 `01a06147-0837…`	26136	14:40:43

Peak: 7 ralhf-local processes for 4 chats, ~870 MB working set for a server that was idle in every one of them (our bridge logs show only startup.begin / startup.ready, no tool calls, for 6 of the 7).

Lifecycle signals from logs_2.sqlite

The hidden threads were unloaded exactly 30 min after creation by the app-server idle rule, which killed their MCP children:

14:40:43 INFO codex_app_server::request_processors::thread_lifecycle
         thread 01a06147-0837-7142-af60-3d9589c1c767 has no subscribers and is idle; shutting down
14:40:43 INFO codex_core::session::handlers ... codex.op="shutdown": Shutting down Codex instance
14:40:43 INFO rmcp::transport::child_process ... session_init.mcp_manager_init ...
         mcp.runtime.refresh:new{server_name=ralhf-local}:start_server_task{server_name=ralhf-local}:serve_inner:
         Child exited gracefully exit code: 1

The 4 visible chats never hit that rule. They stay subscribed while the Desktop window is open even when a different chat is in front, so their MCP processes live for the whole app session. Switching between chats did not kill or restart anything, it only added.

For comparison, Claude Desktop on the same machine with the same server config keeps exactly one ralhf-local process for all conversations.

Interpretation (this part is inferred): per-thread MCP ownership (session_init.mcp_manager_init on every thread/start) is doing what it is designed to do. The cost is two full MCP process sets per chat, one of which is for a thread the user never sees, and the visible one is never reclaimed until app exit. A project-scoped pool as proposed here would collapse all of the above to one process. Short of that, two smaller mitigations would help a lot on this data: (1) don't start MCP for the hidden second thread when dynamic_tool_count=0 and no turn has run, or (2) let it inherit the parent chat's MCP connections like the subagent proposal above.

Happy to share the full logs_2.sqlite extract or run a build with extra tracing if useful.

I was also interested in this issue, so I put together a draft implementation of project-scoped MCP connection pooling for the Codex CLI.

Draft implementation:

https://github.com/openai/codex/compare/main...t-tajiri:codex:feat/mcp-connection-pool?expand=1

Scope:

adds the experimental mcp_connection_pool feature flag, disabled by default
shares stdio and Streamable HTTP MCP connections at the app-server level
keys pooled connections by project root and effective connection configuration
evicts connections after 10 minutes of inactivity
routes pooled elicitation requests to the active thread
auto-starts the local app-server daemon for interactive CLI sessions
falls back to the embedded app server if daemon startup fails
excludes codex exec, VS Code sessions, and the reserved codex_apps server
bypasses the pool for explicit MCP refreshes

+1, with measurements from Windows desktop 26.915.4065.0 (backend 0.155.0), 24 cores, 256 GB RAM. Full details are in #46479.

Per-thread MCP ownership is not only wasteful on Windows, it is fatal. Every chat AND every subagent spawns its own copy of every enabled stdio MCP server. With 13 resident stdio servers that is about 23 processes and 1.4 GB per subagent. At about 20 live threads the app-server held 258 direct children (451-process tree, 27 GB) and wedged permanently at 0% CPU, because each piped child pins 2 tokio blocking-pool threads and the pool is capped at 512 (#42740). Measured three times in one evening: waiting threads = 2 x children + 4 (36 -> 76, 103 -> 209, 257 -> 515), freeze at 254-267 children, and again 10 min 44 s after a restart because the desktop resumes about 20 threads with full MCP sets. Across 14 runs every long freeze began at 240-273 live stdio clients; runs that peaked at 214 or less never froze. The desktop's 6-slot request scheduler then turns the unanswered calls into "App server request timed out while queued" in every chat (#38385).

The waste is total. In 5 days of history (558 threads, 5,872 MCP tool calls) 10 of my 13 resident servers were called zero times, yet each was launched for every subagent. Finished subagents are parked with all their MCP children alive (v2 residency only evicts when max_concurrent_threads_per_session is hit); I logged 0 thread shutdowns and all 540 thread_spawn_edges rows are still "open".

Request: a built-in MCP broker.

One instance of each stdio server per app-server or per project root; chats and subagents attach to it. 20 subagents x 13 servers should be 13 processes, not 260.
Lazy start on the first tool call, serving tool lists from the cached catalog.
Reference counting with idle shutdown and restart on demand.
mcp_servers.<id>.scope = "app" | "project" | "thread" for the few servers that really need isolation.
A per-role or per-spawn MCP allowlist so subagents do not inherit the parent's full set.
Release MCP resources as soon as a subagent finishes or is parked.
Show live MCP process count and memory per chat, with a warning before limits.

Users are now building external MCP brokers just to make subagents usable. This belongs in the product.

Navigation Menu

Repository navigation

Codex Desktop should use a project-scoped MCP process pool instead of starting MCP per session #20883

Codex Desktop currently appears to start stdio MCP servers per loaded chat/session instead of sharing them per project/workspace.

Linux headless `app-server` data point (OpenClaw gateway)

Windows data point from Codex Desktop `26.825.6671.0`: one stdio MCP process per thread, plus a second hidden thread per chat, all under one app-server

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Codex Desktop should use a project-scoped MCP process pool instead of starting MCP per session #20883

Description

Codex Desktop currently appears to start stdio MCP servers per loaded chat/session instead of sharing them per project/workspace.

Activity

github-actions commented on May 3, 2026

AIast0r commented on May 3, 2026

AIast0r commented on May 3, 2026

Latand commented on May 6, 2026

mySebbe commented on May 11, 2026

mySebbe commented on May 11, 2026

mySebbe commented on May 12, 2026

mySebbe commented on May 12, 2026

mnuradli1 commented on May 19, 2026

Linux headless app-server data point (OpenClaw gateway)

Keesan12 commented on Jun 6, 2026

AIast0r commented on Jun 10, 2026

wherewolf87 commented on Jul 13, 2026

LukeMainwaring0 commented on Jul 15, 2026

AIast0r commented on Jul 15, 2026

marcelosaltori commented on Jul 24, 2026

AIast0r commented on Jul 24, 2026

luvs01 commented on Aug 7, 2026

boombx403-byte commented on Aug 18, 2026

kjetilh commented on Aug 27, 2026

ankush-botfood commented on Sep 2, 2026

Windows data point from Codex Desktop 26.825.6671.0: one stdio MCP process per thread, plus a second hidden thread per chat, all under one app-server

t-tajiri commented on Sep 8, 2026

wherewolf87 commented on Sep 21, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Linux headless `app-server` data point (OpenClaw gateway)

Windows data point from Codex Desktop `26.825.6671.0`: one stdio MCP process per thread, plus a second hidden thread per chat, all under one app-server