Repository navigation
[Windows 26.1002.6548.0] Codex Desktop accumulates repeated MCP/CUA/node_repl process batches, reaching 200 Node helpers and ~11.6 GB private memory #51649
Description
What version of the Codex App are you using (From “About Codex” dialog)?
OpenAI.Codex 26.1002.6548.0
What subscription do you have?
ChatGPT Pro 20x
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
Codex Desktop on Windows progressively accumulates repeated local Node/MCP/CUA/node_repl helper process batches while the same desktop app-server remains running.
The process count and private committed memory increase over time during normal multi-session Codex work. Eventually this creates severe Windows memory pressure and paging, and Codex sessions become dramatically slower.
In my workload, tasks that normally finish in tens of minutes can take 2–4 hours when multiple Codex/Claude sessions are active.
Observed Codex process accumulation
During one long-running Codex Desktop app-server session, I measured:
- 200 Codex-owned Node-family processes in total
- 110 MCP-related Node processes
- 52 CUA Node processes
- 38 node_repl processes
- approximately 11.62 GB of private memory across those Node-family processes
The process creation timestamps showed repeated batches throughout the lifetime of the same app-server, including several bursts of exactly 11 processes.
Examples from the creation timeline:
2026-10-06 21:03 11
2026-10-06 21:06 11
2026-10-06 21:48 11
2026-10-06 22:35 11
The helpers were not simply the fixed startup cost of Codex.
Clean restart comparison
After fully exiting Codex Desktop:
- the Codex app-server disappeared
- Codex-owned node_repl/code-mode helpers disappeared
- Windows committed memory dropped from 63.06 GB to 41.44 GB
- this released approximately 21.62 GB of system commit
After starting Codex Desktop again, the clean baseline was only:
CodexNodeCount: 8
With three Codex sessions actively executing tasks, the process tree became:
NodeTotal : 44
MCP : 24
CUA : 12
NodeRepl : 8
NodePrivateGB : 2.54
CodexTreePrivateGB : 3.30
No additional visible Codex session was started.
Approximately 10 minutes later, while the same three sessions were still running:
NodeTotal : 55
MCP : 30
CUA : 15
NodeRepl : 10
NodePrivateGB : 3.18
CodexTreePrivateGB : 4.00
The increment was exactly:
+6 MCP
+3 CUA
+2 node_repl
= +11 processes
This looks like another complete local runtime/helper batch being created while previous batches remain resident.
System impact
The machine has approximately 32 GB physical RAM.
Before cleanup, under the full workload, I measured:
CPU average : 70.73%
CPU maximum : 100%
Available memory minimum : 494 MB
Committed memory : 87–90%
Pages/sec average : 6585.5
Page Reads/sec average : 918.7
Windows was under severe paging pressure.
Docker was initially also running and amplified the memory pressure, so I stopped Docker.
After Docker was stopped, system pressure improved substantially, but the Codex helper accumulation still reproduced:
Clean Codex start: 8 Node-family helpers
3 active sessions: 44 helpers
~10 minutes later: 55 helpers
Therefore Docker is not required to reproduce the Codex process accumulation.
There is no single application error dialog or explicit Codex error message. The observable failure is progressive helper-process accumulation, increasing committed/private memory, heavy paging, and severe degradation of Codex task throughput.
What steps can reproduce the bug?
-
Fully exit Codex Desktop.
-
Verify that the previous Codex app-server and its node_repl/code-mode helper tree have exited.
-
Start Codex Desktop again.
-
Immediately inspect the Codex app-server descendant processes. On my machine, a clean startup has approximately:
NodeTotal: 8
- Start several normal Codex sessions. In my reproduction I used three concurrently active sessions.
The tasks were normal software-development/agent tasks involving local tools. Reasoning effort was generally Low or Medium; Fast mode was not enabled.
- Periodically inspect the
codex.exe app-serverdescendant process tree.
For example, the following PowerShell script counts the Node-family descendants and classifies them without printing complete command lines:
$all = Get-CimInstance Win32_Process
$root = $all |
Where-Object {
$_.Name -eq "codex.exe" -and
$_.CommandLine -match "app-server"
} |
Select-Object -First 1
if (-not $root) {
throw "Codex app-server not found"
}
$rootId = [int]$root.ProcessId
$desc = New-Object 'System.Collections.Generic.HashSet[int]'
$null = $desc.Add($rootId)
$changed = $true
while ($changed) {
$changed = $false
foreach ($proc in $all) {
$childProcessId = [int]$proc.ProcessId
$parentProcessId = [int]$proc.ParentProcessId
if (
$desc.Contains($parentProcessId) -and
-not $desc.Contains($childProcessId)
) {
$null = $desc.Add($childProcessId)
$changed = $true
}
}
}
$nodes = $all |
Where-Object {
$_.Name -in @("node.exe", "node_repl.exe") -and
$desc.Contains([int]$_.ProcessId)
}
$runtime = @{}
Get-Process -ErrorAction SilentlyContinue |
ForEach-Object {
$runtime[$_.Id] = $_
}
$rows = foreach ($proc in $nodes) {
$text = "$($proc.ExecutablePath) $($proc.CommandLine)"
$category =
if ($proc.Name -eq "node_repl.exe") {
"node_repl"
}
elseif ($text -match "cua_node") {
"CUA"
}
elseif ($text -match "mcp") {
"MCP"
}
else {
"Other"
}
$processId = [int]$proc.ProcessId
$rp = $runtime[$processId]
[pscustomobject]@{
Category = $category
PrivateMB = if ($rp) {
[math]::Round($rp.PrivateMemorySize64 / 1MB, 1)
}
else {
0
}
}
}
$rows |
Group-Object Category |
ForEach-Object {
[pscustomobject]@{
Category = $_.Name
Count = $_.Count
PrivateGB = [math]::Round(
(($_.Group | Measure-Object PrivateMB -Sum).Sum / 1024),
2
)
}
} |
Format-Table -AutoSize
"Total Node-family processes: $($nodes.Count)"- With three active sessions, I observed:
NodeTotal: 44
MCP: 24
CUA: 12
node_repl: 8
- Approximately 10 minutes later, without starting another visible session:
NodeTotal: 55
MCP: 30
CUA: 15
node_repl: 10
This is an additional complete batch of:
6 MCP + 3 CUA + 2 node_repl = 11 processes
-
During a longer app-server lifetime, allow normal Codex work to continue. In my earlier run the same app-server eventually reached approximately 200 Codex-owned Node-family processes and ~11.6 GB of Node private memory.
-
Fully exit Codex Desktop.
The accumulated Codex helper tree is cleared and system committed memory drops substantially.
- Reopen Codex Desktop.
The process count returns to the clean baseline (approximately 8 on my machine), and then begins growing again as tasks execute.
Session/context information
This problem was observed across several concurrent Codex sessions rather than one specific prompt.
- Concurrent visible sessions during the clean reproduction: 3
- Reasoning effort: normally Low or Medium, rarely High
- Fast mode: normally disabled
- The issue appears related to local runtime/helper lifecycle rather than a specific model response or prompt
- Session IDs are not included in this public issue, but I can provide relevant thread/session identifiers privately if maintainers need them
What is the expected behavior?
Codex Desktop should keep the number of local MCP/CUA/node_repl helper processes bounded.
A new task, tool turn, subagent, or runtime context should not indefinitely add another complete local helper/MCP process batch.
When a runtime is no longer needed, its local stdio MCP/CUA/node_repl process tree should be terminated or safely reused.
Long-running Codex Desktop usage with several sessions should not require periodically restarting the entire application to recover tens of gigabytes of committed memory.
The expected behavior is:
- bounded helper-process count
- reuse or teardown of obsolete runtime/MCP process pools
- stable private/committed memory over long-running sessions
- no progressive Windows paging or system-wide slowdown caused by retained Codex helper processes
Additional information
Codex app-server configuration
The affected Codex Desktop app-server was launched with this general command shape:
codex.exe
-c features.code_mode_host=true
app-server
--analytics-default-enabled
-c features.prefer_mxc=true
-c plugins.codex-app-tools@openai-bundled.mcp_servers.codex_app.enabled=true
-c plugins.code-review@openai-bundled.mcp_servers.code-review.enabled=true
No credentials or private project information are included above.
Hardware
- approximately 32 GB physical RAM
- DDR5-5600
- Windows x64
- Docker was stopped during the clean reproduction described above
Important A/B observation
Before fully exiting Codex:
CommittedGB: 63.06
After fully exiting Codex:
CommittedGB: 41.44
Difference:
~21.62 GB system commit released
After restarting Codex:
Initial Codex Node-family helper count: 8
The helper count then increased again as normal Codex work continued.
This makes the condition highly reproducible and strongly tied to the lifetime of the Codex Desktop app-server/process tree rather than permanent OS memory usage.
Possibly related existing reports
This may be related to the same Windows MCP/helper lifecycle problem reported in:
- [Windows 26.818] MCP process-batch accumulation and incomplete cleanup still reproducible with 5 MCP servers #40579
- [Windows 26.707] Codex Desktop retains five MCP/Node process batches (147 node.exe, 13.9 GiB) #32797
- [Windows App 26.707.9981.0] MCP suites persist after subagents complete, reaching 10.9 GB private memory #33531
- Codex Desktop on Windows accumulates Node REPL/MCP/stdio app-server helper stacks during long multi-thread sessions #26327
I am filing this separately because the issue is still reproducible on the much newer Codex Desktop version 26.1002.6548.0, and I have a clean restart baseline plus process-count/memory measurements showing the progression from 8 -> 44 -> 55 -> approximately 200 helpers during longer-running usage.
Activity
github-actions commentedon Oct 7, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Sambhav242005 commentedon Oct 13, 2026
Additional Windows measurements from 2026-10-13, shared with the user's authorization.
Environment:
codex-cli 0.162.0-alpha.17.2.Observed snapshots during normal desktop use:
node.exehelpers with approximately 1,460 MiB of private committed memory.The distinction between private committed memory and resident working set matters here: an earlier snapshot showed only about 5 MiB resident across the helpers, despite substantial private committed memory. Most of the allocation was therefore not resident at that instant; low resident memory alone did not establish low overall memory overhead.
This is an additional observation of significant helper-process overhead on a 16 GB Windows machine. These snapshots do not establish monotonic process accumulation, a confirmed leak, that the helpers were obsolete, or how much physical RAM terminating them would recover. We did not terminate the helpers or perform a restart A/B comparison because they could support other chats and tools.
Please investigate whether local helper pools can be reused or safely released when their associated tool contexts are no longer needed, and whether the app can expose an idle-helper cleanup option or memory diagnostics.
No session transcripts, credentials, local usernames, project paths, or complete process command lines are included.
medz commentedon Oct 16, 2026
Additional macOS measurements, with a possible contributing mechanism in composer prediction forks. This is performance/resource-usage feedback; the trace does not establish a permanent memory leak.
Environment
codex-cli 0.163.0-alpha.10.2.Measurements
At 2026-10-17 00:23:59 UTC+08:
RSS includes shared pages. These totals are not exclusive physical memory, Activity Monitor footprint, or Windows private committed memory. We did not individually establish that all 19 temporary cohorts were composer predictions.
Each representative cohort contained a code-review server, app-tools server, CUA server/child, node_repl helpers, and an npm launcher plus XcodeBuildMCP service. Their temporary turns completed at 2026-10-16 23:43:30 and 23:43:52 UTC+08, adjacent to corresponding
cumberbatchprediction-decision log events. Both sets of helpers remained alive at 00:23:59, roughly 40 minutes after those prediction completions.During subsequent checks around 00:32 and at 00:33:55, all 16 tracked PIDs had exited. Across five older cohorts, 40 helper PIDs had exited, while the original app-server PID was unchanged. This diagnosis did not terminate those helpers or restart the application.
Other development tasks continued throughout, so these observations are not an isolated A/B test and do not establish monotonic accumulation.
Source-supported contributing mechanism
Read-only inspection of the installed desktop bundle shows that
composer_predictionsuses an ephemeral fork withexperimentalPredictionMode: true. Its shared generation helper callsunsubscribeThreadinfinally, ignoring errors.In the matching public tag, prediction forks inherit parent configuration, including client MCP extensions. Non-SubAgent sessions use Eager MCP startup. This provides a mechanism for short prediction requests to start a complete local toolchain even when they do not execute those tools.
The normal lifecycle deadline and timer use the later of the no-subscriber and inactive timestamps, plus 1800 seconds, followed by session shutdown and removal. We did not capture the actual last-unsubscribe timestamp. Forty minutes after prediction completion alone therefore does not prove a retention-deadline violation.
Could prediction forks retain the model's tool declarations and prompt-cache reuse while avoiding eager startup or extended retention of local tool processes they do not need to execute?
The confirmed observation is substantial helper-process overhead, with a source-supported contributing mechanism. Permanent retention and a heap leak remain unproven.
jaehyunseo-119 commentedon Oct 17, 2026
Additional Windows observations: helper accumulation and a short predictions-OFF comparison
Adding Windows measurements to complement medz's prediction-fork analysis. These observations do not establish a permanent leak or a confirmed root cause.
Environment and scope
OpenAI.Codex_26.1013.4894.0(package version, not CLI version).During extended use, conversations became increasingly unresponsive. Restarting temporarily improved responsiveness and substantially reduced process counts. No OOM diagnosis was captured.
Observations before disabling predictions
codex.execmd.exe, 59node.exe, 50node_repl.exe, and 29uvx.exenode.exesnapshotsThese are separate observations, not one continuous series. The system-wide Node counts are not a claim that every process belonged to Codex. The increasing batches included Codex tool runtimes; no project web-server listeners were found on the checked QA ports during that inspection.
Logs recorded
thread/forkand subsequent turn completion. The four retained processes were correlated by creation time and tool type, not an explicit thread-to-PID ownership mapping. Turn completion is not equivalent to thread teardown; this retention interval does not demonstrate a cleanup-deadline violation.After disabling Show predictions and restarting
The setting was turned OFF through the UI, followed by a full application restart. An initial approximately 41-second observation showed
node.exeremaining at 11, with no observed Node births/exits or newthread/forkrecords in the inspected logs.Four sequential text-only request/reply exchanges were then performed with one existing chat. The first exchange loaded another tool-runtime cohort: Node increased from 11 to 21. The receiving chat was instructed not to execute tools or resume project work.
The three additional exchanges and a later development-work checkpoint were sampled as follows (all counts are system-wide for the named executables):
node.execmd.exenode_repl.exeuvx.exeDuring the text-only test, all ten temporarily added processes had exited by the follow-up. The final text-only snapshot matched the baseline PIDs and creation timestamps. No additional
thread/forkrecords were found in the inspected interval. The source of the transient processes was not conclusively identified.¹ The 06:01:52 snapshot was taken approximately 80 minutes after the final text-only checkpoint, after concurrent development work had resumed with Show predictions still disabled. This was not continuous monitoring or an unchanged-workload comparison.
At this checkpoint, 125
node.exeprocesses were identified by parent-process traversal as descendants of three Codex app-server processes, with approximately 8,773 MiB of summed private memory—not physical RAM usage. Two of those app-server processes had started after the text-only test. The earlier text-only test did not yield a valid comparable memory measurement, so no memory-growth delta is claimed.Despite the higher process counts, the previously observed delays, timeouts, and UI unresponsiveness had not recurred according to the user’s observation during approximately one hour of concurrent work. This supports improved responsiveness during the observed period, but does not establish that process growth stopped or that retained helpers were unnecessary.
User-observed responsiveness after the change
Since disabling Show predictions and restarting Codex, the previously recurring conversation delays, timeouts, and application sluggishness have not recurred during continued use up to this update. Conversations are currently responsive. This is a clear user-observed improvement, although the separate effects of disabling predictions and restarting have not been isolated.
Interpretation and limitations
The predictions-OFF run did not reproduce sustained accumulation during this short, text-only test. This is consistent with predictions contributing to the earlier behavior, but disabling predictions and restarting were simultaneous interventions, and the workloads were not identical. Diagnostic activity may also affect process creation.
This does not establish causality, a permanent leak, a cleanup failure, or long-term stability under concurrent tool-heavy workloads. I am contributing the Windows observations and bounded follow-up rather than independently confirming the implementation mechanism described above.
No credentials, private project paths, session identifiers, or raw logs are included.
fkubrick commentedon Oct 18, 2026
Adding another Windows data point from October 18, 2026.
Environment: Windows desktop package
OpenAI.Codex 26.1013.4894.0, bundled CLI0.163.0-alpha.10.2, approximately 31.6 GiB usable physical RAM, several development chats and local stdio MCP servers configured.Observed before any local mitigation:
Measurement limits: these were snapshots during real concurrent work, not an isolated A/B experiment or continuous growth trace. System memory changes cannot be attributed entirely to Codex. Summed working sets include shared pages and are not exclusive physical memory or private committed memory. Multiple MCP instances can legitimately belong to distinct clients. We have not established a permanent leak, a missed teardown deadline, an OOM event, or a link to composer predictions.
The practical impact was application unresponsiveness requiring a restart. It would be useful to investigate the startup/retention cost of local MCP servers and npm/npx wrappers, including deferred startup until first use and bounded teardown of unused runtimes. Any reuse would need to preserve per-session state and credentials.
Only sanitized aggregate observations are included; no local paths, project names, credentials, session IDs, screenshots, or raw logs are attached.
pozafly commentedon Oct 19, 2026
Adding a macOS observation that complements the prediction-fork findings above.
Environment: Codex Desktop 26.1013.40934, bundled CLI 0.163.0. Composer predictions remained enabled. I set
thread_unload_delay_secs = 300and restarted the app before the observation.node_replprocesses, two Node MCP servers, and one CUA launcher. There was also a native event-stream helper outside that Node count.So this observation demonstrates repeated startup and temporary retention overhead, rather than establishing a permanent process leak. Reducing the unload delay limits how long these cohorts accumulate, but does not prevent a new cohort from starting for each prediction.
Could prediction forks skip or defer local MCP/helper startup while preserving composer predictions and normal chat tool access? Predictions are useful; a prediction-specific exemption would address this overhead without disabling the feature globally.
Personal information, local paths, process/thread identifiers, and raw logs have been omitted.
henrikogaard commentedon Oct 19, 2026
Additional macOS observation: ChatGPT desktop 26.1013.40934, build 20770; bundled Codex CLI 0.163.0-alpha.10.2; macOS 27.0.1.
After a normal conversation response, a temporary
composer_predictionsfork started a separate tool-worker bundle. The prediction completed after approximately 12 seconds. Six associated Node/Node REPL processes remained alive approximately 21 minutes later, with a summedvmmapphysical footprint of about 192 MiB.Backend logs show shutdown of the temporary thread exactly 30 minutes after prediction completion. All six workers subsequently exited without intervention, while the original app-server and conversation workers remained running.
This observation supports substantial temporary tool-runtime overhead, not a permanent leak or failed cleanup. Please investigate avoiding tool-process startup for composer predictions that do not use tools, or releasing their runtime resources sooner.
This was a read-only investigation of one observed prediction lifecycle, not an isolated repeated reproduction.
MaksymShostak commentedon Oct 19, 2026
Additional Windows incident evidence from October 19, 2026, posted with the workstation owner's authorization. Adding to this existing report rather than opening another duplicate; also relevant to #53285.
Environment verified during follow-up
OpenAI.Codex_26.1013.4894.0_x64.codex-cli 0.163.0-alpha.10.2.codex.exe app-serverhad been running since approximately 09:26 local time (UTC+03).Incident and recovery recorded in the owner's local diagnostic report
At approximately 17:00, the report recorded roughly 1,100 processes across Windows, with approximately 800 classified as Codex/MCP-related. Reported instance counts included:
node.execonhost.exenode_repl.execmd.exegithub-mcp-server.exeRepeated command families included Chrome DevTools through
cmd /c npx, GitHub MCP stdio, CUA/Node REPL, Codex Security, Codex App Tools, and Code Review. The report recorded approximately 29–35 copies of several server/launcher families beneath one live app-server. Severe workstation sluggishness was observed.The report's recovery at approximately 17:07 explicitly terminated 520 selected tool/launcher processes while retaining the app-server. Its before/after snapshots recorded:
The report summed approximately 23.8 GB of working sets before cleanup. That is not exclusive physical-memory attribution: shared pages may be counted multiple times. The observed approximately 7.66 GiB increase in available memory is a separate host-level before/after measurement during a live workload, not an exact per-component accounting.
Independent read-only follow-up
At 17:13 local time, I verified the original app-server PID and creation timestamp were unchanged. A fresh parent/child traversal found 121 descendants (35 direct children), including seven GitHub MCP processes with creation times after 17:07, eleven
node_repl.exeprocesses, and repeated DevTools/tool families. The host had 442 processes and approximately 10.61 GiB available physical memory.Other chats and diagnostic work were active. This follow-up establishes that helper processes were being created again under the same app-server after the reported cleanup; it does not establish that these newly created instances were obsolete or leaking.
Interpretation and requested investigation
The raw pre-cleanup per-PID capture was not included in the supplied report. Its stronger claims of universal orphaning, missing stdin-EOF handlers, missing Job Objects, and a proven permanent leak are therefore not independently established by this submission. A live app-server surviving child termination also does not prove every terminated child was unused.
The matching public configuration schema documents
thread_unload_delay_secswith a default of 1800 seconds, and unloading depends on both inactivity and no subscribers. The workstation's inspected user config has no override. Turn completion alone cannot establish that a teardown deadline was missed. No controlled HISEW-on/off or predictions-on/off reproduction was performed.HISEW Dev 0.1.0-dev.27 is installed on this workstation. Its installed manifest declares skills and SessionStart/Stop hooks, with no MCP server declaration. Its review workflows can cause additional agent sessions, so workload amplification is possible, but this evidence does not attribute the retention defect to HISEW.
Please investigate bounded lifetime/ownership for normal, subagent, and internal temporary sessions; avoid starting full local tool bundles for prediction/summary work that does not use them; and expose enough runtime ownership to distinguish actively needed workers from retained pools. Windows process-tree containment remains relevant at actual shutdown, but it would not by itself reclaim runtimes that Codex deliberately keeps alive.
No credentials, raw logs, session identifiers, local usernames, or private project paths are included. The incident measurements above are explicitly distinguished from the fresh follow-up and from causal hypotheses.
jordanlein commentedon Oct 19, 2026
Adding a related Windows data point, with the workstation owner's authorization. Detailed measurements and limitations are in #53285 (comment) to keep the full report in one place.
On Windows 11 Pro build 26300, desktop package 26.1013.4894.0, a live Codex process tree contained 24 node.exe helpers and 12 MATLAB MCP processes arranged as six parent/child pairs with distinct creation-time batches under the same backend. Several groups also included Firebase and computer-use helpers.
Summed desktop-tree working set/private bytes were 6692/6345 MiB before restart, 5591/5502 MiB after the user terminated and reopened Codex, and 5145/4838 MiB after MATLAB MCP removal. Corresponding node.exe counts were 24 -> 19 -> 10; MATLAB connector counts were 12 -> 4 -> 0. Two new helper batches appeared within approximately the first minute after reopening.
These are interactive diagnostic snapshots, not an isolated workload comparison. Shared pages are double-counted in summed working sets; private bytes are commit, not physical RAM. The observed decreases and cleanup do not establish a permanent leak or that retained helpers were unnecessary. The useful signal is repeated startup/retention overhead on this version, with a measured restart comparison.
efrasmsq-sudo commentedon Oct 19, 2026
Windows confirmation: composer prediction forks initialize MCP runtimes (2026-10-19)
Adding a source/runtime correlation to this existing report with the workstation owner's explicit authorization. This identifies a concrete contributing mechanism, not proof of a permanent leak or attribution of every helper process.
Verified environment: Windows x64; MSIX package
26.1013.4894.0; packaged desktop application26.1013.40934; executing backendcodex-cli 0.163.0-alpha.10.2. This was an existing, long-running profile with multiple configured MCP integrations, not an isolated clean-install workload.Local runtime evidence
cumberbatch_safety_decisionevents for composer predictions in the active conversation during the diagnostic window.rpc.method="thread/fork"->thread_spawn->session_init.mcp_manager_init-> MCP client initialization for multiple configured servers.Installed implementation and matching-version source
Read-only inspection of the shipped desktop JavaScript found:
experimentalPredictionMode: true,ephemeral: true, andthreadSource: "composer_predictions".unsubscribeThread; it does not request immediate runtime destruction. Unsubscribe errors are caught without surfacing a cleanup failure.The corresponding public version provides the rest of the lifecycle mechanism:
That allows repeated predictions to retain overlapping tool-runtime cohorts even when no extra task is visible. The 30-minute value is a source-confirmed default, not a measured teardown deadline or demonstrated missed deadline on this workstation. The public tag matches the backend's reported version; this is not a bit-for-bit build provenance claim.
Requested fix and evidence limits
Please avoid initializing full MCP/tool runtimes for prediction-only work that does not use tools, and release temporary-fork resources promptly through a bounded lifecycle. Expose runtime ownership so users can distinguish active workers, deliberate retention, and failed cleanup without periodically terminating processes.
No predictions-OFF controlled comparison or full idle-to-shutdown lifecycle was performed here. No claim is made that this mechanism explains all CPU use, all helpers, or a permanent leak. The concurrent access-denied catalog retry loop is reported in #53677, not established as the trigger for MCP spawning.
Intervention disclosure: selected helper processes had been terminated earlier in this incident. At least one later transport-closed error followed that cleanup and must not be used as evidence of the original defect. The subsequent source/runtime investigation did not repeat process termination or modify installed code, credentials, databases, caches, or security settings.
Privacy: no raw logs, private chat/request/account IDs, prompts, project names, personal paths, process command lines, credentials, screenshots, or attachments are included.