Long-running Codex sessions lead to whole-PC/laptop lag and freezing on Windows

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

• #32339
• #33319

Powered by Codex Action

Additional sanitized Windows evidence isolates sustained CPU and memory usage in long-lived code-mode kernels.

Environment:

• Codex Desktop/MSIX: OpenAI.Codex 26.715.4045.0
• Windows 11 25H2, build 26200.8037, x64

Observed at 22:18 local time:

• Five node.exe code-mode kernels created between 12:55 and 14:00 were still alive more than eight hours later.
• Together they consumed 32.617% of total machine CPU and approximately 7,550 MB of private memory.
• The desktop app-server consumed another 8.125% CPU.
• Total measured machine load was 45.02%, with 542 processes.
• Each kernel still had an immediate codex-command-runner, but the parent PID recorded by that runner no longer existed in the live process table.

Activity qualification:
Native task state plus owner confirmation identified three kernels as belonging to an idle task. Two other kernels belonged to a task that was still actively in use, so those two were protected and were not classified as orphaned.

Controlled mitigation:

• Only the three proven idle kernels were selected after exact PID, creation-time, session, working-directory, and parent-chain validation.
• Their three command runners exited automatically.
• Readback confirmed all six targeted PIDs were absent.
• Whole-machine CPU fell from 45.02% to 21.39%.
• The active task and current task were not affected.
• No Codex or Windows restart and no configuration change were performed.

The two protected kernels associated with the active task continued to use 16.954% CPU. This is not enough to classify them as orphaned, but it shows that selective cleanup only removes proven stale instances and does not fix the lifecycle behavior.

Expected:
A code-mode kernel should terminate or become effectively idle when its task is idle and its controlling parent chain has disappeared.

Actual:
Three kernels from an idle task remained alive for more than eight hours, consumed sustained CPU and multiple gigabytes of memory, and required targeted runtime cleanup.

No task content, local paths, usernames, credentials, or raw command lines are included.

New controlled Windows evidence: parentless Codex runner trees survived app-server replacement and consumed ~35 CPU percentage points

Additional controlled evidence substantially narrows this issue.

Environment confirmed in the same source task:

• Codex Desktop: 26.715.10079.0
• Bundled CLI/app-server: 0.145.0-alpha.30
• Active codex.exe SHA-256: ADF966822B9A04FB3A6E41D7D6A44B60E5C87BEAC6AEBEF5C0B0A2205C8CDF62
• Windows 11 x64

The exact Windows build and timestamped version pin inside each individual sample were not retained, so I am not inferring them.

Pre-action validation

Five exact runner → conhost → node branches were selected only after a repeated identity gate confirmed:

• each runner’s recorded kernel parent was absent;
• each branch predated the current app-server, created at 11:56:14.912 +03:00;
• the branches had therefore survived the relevant app-server replacement boundary;
• a similar branch belonging to a live task was explicitly excluded;
• PID identity was protected by creation-time validation.

No global process-name scan or blanket process killer was used.

Controlled before/after result

| Metric | Before | After |
|---|---:|---:|
| Sampling window | 8.68 s | 8.48 s |
| Average system CPU | 77.9% | 41.5% |
| Maximum system CPU | 89.6% | 64.6% |
| System memory used | 30.0% | 24.38% |
| Five selected branches | 35.19 CPU percentage points | 0 |
| Selected working set | 3,311.5 MiB | 0 |
| Selected private memory | 3,749.8 MiB | 0 |
| Exact target processes present | 15 | 0 |

Only the five validated runner roots were stopped. Their children exited naturally. Final readback confirmed 0/15 exact target processes remained.

The active task branch, current app-server, Codex Desktop, Windows services, Codex configuration, and Codex state were not changed.

Human impact

This was not a harmless process-count anomaly. The five retained branches accounted for roughly 35 percentage points of system CPU and 3.75 GiB of private memory while the machine was being used for normal work.

The only demonstrated relief was manual, identity-gated process termination. That is not an acceptable user-facing solution: a valid active task can have a structurally similar runner → node branch, so a global scanner or process killer can destroy legitimate work.

The user is left choosing between sustained high CPU/memory, restarting Codex, or performing risky manual process forensics. Repeated diagnosis and selective cleanup also consume substantial working time and model usage without preventing recurrence.

What remains unknown

Current telemetry does not expose:

• the thread/session owner of each retained runner;
• whether release or shutdown was requested for that owner;
• whether shutdown was never invoked or was invoked and failed;
• the exact product path that produced each retained branch.

This report therefore does not claim that every retained process has the same cause, that every suite is permanently orphaned, or that the behavior is related to a BSOD.

Requested product behavior

Codex should:

1. retain an authoritative mapping from owner/thread/session to runner PID and creation time;
2. request shutdown at the supported lifecycle release boundary;
3. await and verify disappearance of the exact process tree;
4. report a structured result such as tree_absent, timeout, termination_failed, or ownership_unknown;
5. preserve active neighboring tasks;
6. handle child-exited-first races and PID reuse;
7. surface and validate the Windows termination result instead of treating process launch as cleanup success.

A durable fix should include Windows tests for archive/release, delayed unsubscribe, an active neighboring task, child-before-parent exit, PID reuse, app-server restart, background automation ownership, and final exact tree-absence readback.

This evidence strengthens the conclusion that Codex needs owner-aware, positively verified process-tree cleanup. Manual selective termination is only a temporary workaround.

I can reproduce the same issue after a Windows desktop app update on 2026-08-14, and the new build still appears affected.

Environment

• Windows 11
• Current Microsoft Store package: 26.810.4967.0
• Previous package: 26.803.10989.0
• Chromium executable version: 151.0.7922.137
• 32 GB RAM

Reproduction and behavior

1. Launch Codex Desktop and use it for tool-heavy work involving local shell, web/browser, and JavaScript MCP calls.
2. Leave the app minimized or resident in the system tray after the work finishes.
3. After some time, the whole Windows desktop becomes increasingly laggy.
4. Fully exit Codex from the system tray.

Exiting Codex immediately restores normal system responsiveness.

Sanitized diagnostic snapshot

During one affected-session investigation, the Codex-related process family used approximately:

• 2.2 GB working set
• 14,654 handles
• 714 threads

One ChatGPT GPU process alone retained approximately 380–550 MB working set, 7,300 handles, and 200 threads.

The configured node_repl STDIO MCP uses the OpenAI-provided node_repl.exe. Its process count increased during diagnostics from 7 to 10 and then 13. Some short-lived instances exited, but several older instances remained after tool calls. Each retained instance used about 10 MB, 140–149 handles, and 20 threads. This does not prove that every instance is leaked, but it is consistent with incomplete helper/session cleanup.

At the snapshot time, Windows still had about 15.6 GB of 31.3 GB RAM available, so the machine was not simply out of physical RAM. I also found no Windows Resource Exhaustion Detector event, GPU reset event, or Codex crash event. The only configured automation was paused.

Expected behavior

When tasks finish and the app is idle or backgrounded, unused MCP/runtime, GPU, and renderer resources should be released or suspended. Keeping the app resident should not progressively degrade system responsiveness.

Workaround

Fully exiting the desktop app from the system tray after use resolves the lag.

I have intentionally omitted raw logs, usernames, local paths, and task content. This build-specific reproduction suggests the Windows helper-process / Chromium resource-lifecycle issue remains present in 26.810.4967.0.

Follow-up with a corrected restart/recurrence timeline and a live affected-state sample:

The app was fully restarted before this recurrence. The new desktop root process started at 2026-08-14 20:21:56 local time. Approximately 83 minutes later, the same system-wide lag returned. Therefore, restarting clears the bad state only temporarily; the problem rebuilds during the lifetime of a fresh app process.

Live sample after recurrence

The affected process was the root ChatGPT.exe desktop process (no --type=renderer or --type=gpu-process argument), not a renderer, GPU process, or node_repl.exe.

Across repeated samples:

• Root process CPU remained at approximately 112%–155% of one core (about 133% average).
• Its working set/private memory fluctuated rapidly around 0.8–1.6 GB.
• In one 10-second interval it reported 11,058.7 MB read across 22,414 read operations, averaging about 505 KB per operation.
• A separate 8-second interval reported 6,956.1 MB read across 14,091 operations.
• Writes were negligible.

This was not equivalent physical-disk or network traffic:

• Physical disk reads averaged about 0.075 MB/s (maximum about 0.377 MB/s).
• Network traffic averaged about 0.005 MB/s.
• Available physical memory remained about 14.9 GB.
• Total system CPU was about 12.5%, with processor queue length 0.
• GPU utilization for the Codex GPU process was about 0.15%.

The evidence is therefore consistent with a tight loop involving cached/local-state reads, memory-mapped data, or another internal desktop-process read path rather than disk saturation.

Checks against other suspected causes

• node_repl.exe: 8–10 instances, approximately 78–98 MB combined, near-zero CPU.
• Full descendant-process I/O reconciliation found no child process writing data at a rate matching the root process's reported reads.
• The 238.7 MB logs_2.sqlite file did not grow during the sample.
• Its SQLite sequence advanced by only 5 in 10 seconds, with a net increase of 1 retained row, so this was not an active log-write storm.
• No Resource Exhaustion Detector event, GPU reset, or Codex crash event was found.

Updated conclusion

This is reproducible after a genuine full restart of Windows Codex Desktop 26.810.4967.0. The current direct symptom is a sustained high-CPU/high-cached-read loop in the desktop root process. node_repl lifecycle behavior may still be a secondary concern, but it was not the direct cause of this recurrence.

Raw logs, local paths, usernames, and task content are intentionally omitted. A short WPR/ETW or Process Monitor trace captured during the affected state would be the next useful artifact if maintainers can specify the preferred providers and redaction boundaries.

Update: the issue remains reproducible in the Windows desktop package released/installed on 2026-08-15.

Affected build

• Codex Desktop package: 26.810.6296.0
• Windows 11
• Fresh desktop root process started at 2026-08-15 10:08:14 local time
• Lag recurred after approximately 70 minutes of uptime

Live affected-state sample

The root ChatGPT.exe desktop process again showed the same signature previously captured on 26.810.4967.0:

• Sustained CPU: 131.4% of one core over 10 seconds
• Read transfer: 10,939.3 MB in 10 seconds
• Read operations: 22,176
• Average reported read size: 505.1 KB
• Writes: only 613.3 KB
• Working set: 1,056.2 MB
• Private memory: 1,156.4 MB
• Handles: 2,762
• Threads: 82

The overall Codex desktop process family had 9 ChatGPT.exe processes using approximately 2.8 GB working set.

Control measurements during the same affected state:

• Physical disk reads: 0 bytes/sec across the 5-second sample
• Available physical memory: approximately 15.65 GB
• Total system CPU: 13.5% average
• Processor queue length: 0
• Highest observed Codex GPU-engine utilization: approximately 4.5%
• node_repl.exe: 8 instances, approximately 78.1 MB combined, with no evidence that they were the active CPU source

Conclusion

The 2026-08-15 build 26.810.6296.0 does not fix this issue. After a genuine fresh start, the desktop root process again enters a sustained high-CPU loop with approximately 1.1 GB/sec of reported reads that do not reach the physical disk. The signature closely matches the reproduction on 26.810.4967.0, including the approximately 500 KB average read size.

This further supports a cached/local-state, memory-mapped, or internal desktop-process read loop rather than physical disk saturation, GPU load, RAM exhaustion, or active node_repl computation.

Raw logs, usernames, local paths, and task content are intentionally omitted.

Reproduction on 26.810.6296.0: 322-process MCP/Code Mode avalanche plus Electron-main long-task evidence

I am reproducing the same whole-PC lag and freezing on Windows with Codex Desktop 26.810.6296.0. In the affected state, even the system cursor becomes choppy.

This adds a different layer of evidence to the existing reports: an OS process-tree fingerprint, a controlled no-tracing system sample, and a parsed Chromium content trace.

Strongest facts

• Peak Codex-rooted tree: 322 processes, 3,433 threads, 56,337 handles, 14.7 GB private memory.
• Peak helper breakdown: 175 node.exe, 102 cmd.exe, 34 node_repl.exe.
• The process counts form a repeated runtime signature: approximately 4 MCP Node + 3 cmd + 1 node_repl per runtime copy.
• At peak, four anonymous MCP command fingerprints each had 35 copies, accounting for 140 repeated MCP-labelled Node processes.
• A controlled 28-second sample with content tracing disabled still showed 128–143 Codex-rooted processes and 6.6–7.1 GB private memory.
• During that sample, Electron main averaged 2.607 CPU cores and 316,093 page faults/sec, approximately 98% of all system page faults in the interval.
• In the same 28 seconds, 11 Codex-tree processes were born and 26 exited, showing active process churn/delayed cleanup rather than one static heavy process.
• Chromium trace: browser main executed 33,756 RunMicrotasks slices totaling 9.55 seconds in a 38.36-second timeline, with 43 microtask slices over 100 ms.
• Two click dispatches took approximately 189–190 ms and resolved to repeated 180–183 ms calls at app-initial-BBAkuZJK.js:193:124103.
• Recent logs contained 4,108 ResizeObserver-loop errors (peak 247/minute) plus repeated Git negative-result work (peak 132/minute).
• GPU trace work peaked at 13.6 ms; DPC, disk queue, display-driver reset, WHEA, crash, and OOM evidence did not identify an alternative primary cause.

The 4:3:1 process ratio is particularly strong:

controlled sample:
14 runtime copies
42 cmd       = 14 × 3
14 node_repl = 14 × 1
56 of 60 MCP Node = 14 × 4

peak sample:
35 copies × 4 MCP Node layers = 140 repeated MCP Node processes
expected cmd companions: 35 × 3 = 105; observed 102
expected REPL companions: 35 × 1 = 35; observed 34

The small peak deficit is consistent with capture during teardown. Most retained helpers were 15–30 minutes old; some were older than one hour.

This evidence supports two overlapping problems:

1. delayed or incomplete teardown of task-owned Code Mode/MCP runtime bundles;
2. Electron browser-main ownership/state churn, amplified by the retained runtime population.

The whole-PC cursor symptom overlaps #33074, but the process-lifecycle signature matches this issue directly.

Privacy

The raw trace and logs are intentionally not public because they may contain task content, local paths, URLs, command arguments, and identifiers. The material below was scanned before posting and contains no usernames, absolute paths, repository names, prompts, URLs, tokens, MCP server names, task IDs, process IDs, or machine/network identifiers.

<details>
<summary><strong>Full sanitized evidence report</strong></summary>

Codex Desktop performance collapse on Windows — sanitized evidence report

Report date: 2026-08-15
Product version: Codex Desktop 26.810.6296.0, x64
Report purpose: developer triage, reproduction, and performance debugging
Privacy status: sanitized; no raw trace or raw log content is attached

1. Executive alert

Codex Desktop intermittently becomes severely janky during normal use, without content tracing enabled. The application UI misses frames, clicks can take approximately 190 ms to dispatch, and the Windows cursor can become visibly choppy.

The strongest observed signature is a Code Mode/MCP process avalanche combined with sustained Electron browser-main work:

• peak Codex-owned tree: 322 processes, 3,433 threads, 56,337 handles;
• peak breakdown: 175 node.exe, 102 cmd.exe, 34 node_repl.exe;
• peak Codex-tree private memory: 14.7 GB;
• controlled 28-second sample without content tracing: 128–143 Codex-owned processes, median 137;
• controlled sample Electron-main CPU: 2.607 cores on average;
• controlled sample Electron-main page faults: 316,093/sec on average;
• controlled sample system page faults: 323,019/sec on average, meaning Electron main accounted for approximately 98% of observed faults;
• browser-main trace: 33,756 RunMicrotasks slices, totaling 9.55 seconds in a 38.36-second timeline;
• primary renderer: click dispatches of 189–190 ms and repeated application JavaScript calls of 180–183 ms;
• logs: 4,108 ResizeObserver-loop errors, peaking at 247/minute;
• logs: repeated Git negative-result work peaking at 132/minute.

The evidence supports two overlapping P0 candidates:

1. delayed, incomplete, or excessively long teardown of per-task Code Mode/MCP runtimes;
2. Electron browser-main microtask/state churn, amplified by the retained runtime population.

The trace and Windows event logs do not support GPU execution, display-driver resets, kernel DPC pressure, disk saturation, OOM, or an application crash as the primary cause.

2. Confidentiality and artifact policy

Raw Chromium trace and desktop logs are intentionally excluded because they may contain task text, file paths, URLs, workspace names, command-line arguments, endpoint information, and identifiers.

This report contains only:

• aggregate counts and timing distributions;
• generic executable image names;
• anonymized command fingerprints and runtime counts;
• product, OS, CPU, GPU, and driver versions;
• a Codex-owned production JavaScript bundle location;
• sanitized reproduction commands that do not read task content.

The report excludes:

• user, account, and machine names;
• home-directory and workspace paths;
• repository names and Git remotes;
• prompts, responses, terminal output, and file contents;
• URLs, access tokens, environment values, and command-line arguments;
• MCP server names;
• task, conversation, process, machine, and network identifiers.

The attached machine-readable evidence summary follows the same policy.

3. Test environment

| Property | Value |
|---|---|
| Codex Desktop | 26.810.6296.0, x64 |
| Windows | NT 10.0, build 26200, 64-bit |
| Power plan | High performance |
| CPU | Intel Core i7-13700F, 16 physical / 24 logical cores |
| RAM | 31.8 GB |
| GPU | NVIDIA GeForce RTX 4070 SUPER |
| GPU driver | 32.0.16.1074, dated 2026-07-02 |
| Display refresh | 239 Hz |
| System uptime during investigation | 47.7 hours |
| Codex session uptime during controlled sample | approximately 2 hours |
| Configured MCP server sections | 4; names removed |

The high-performance power plan reduces the likelihood that aggressive power saving caused the result. The high-refresh display makes cursor and frame pacing problems particularly visible but does not explain the process and timing metrics.

4. Evidence sources and method

4.1 Chromium content trace

• format: Chromium/Perfetto JSON trace;
• size: 453.32 MiB;
• parsed events: 2,658,005;
• parse errors: 2 non-event wrapper/terminator lines;
• positive-timestamp timeline: 38,364.65 ms;
• desktop log recording duration: 30,959 ms;
• trace SHA-256: 1C66647854070A968F8B3DCE9F37D93B48E7D3FDB89DBCCD21FFCA46617B0D.

Complete-duration (ph="X") events were aggregated by thread and operation. Durations were converted from trace microseconds to milliseconds. Long-task thresholds were 16.67 ms, 50 ms, and 100 ms. Input analysis used only the event type field; no text or payload was retained.

4.2 Recent desktop logs

• files analyzed: 23 recently modified log files;
• data size: 22.8 MiB;
• lines analyzed: 62,502;
• severity totals: 43,182 info, 7,782 warning, 11,538 error;
• only message-template counts and rates were retained;
• variable values, paths, URLs, identifiers, and payloads were not retained.

4.3 OS process-tree snapshots

Process ancestry was read through Windows process metadata. Command lines were used only in memory to classify generic MCP-related processes and produce one-way SHA-256 fingerprints. No command line or hash-to-command mapping was saved.

Two forms of evidence were captured:

1. peak spot snapshots during the affected app session;
2. a controlled 28-second, 15-sample system measurement with two-second spacing and content tracing disabled.

4.4 Windows system counters and event logs

The controlled sample collected CPU, DPC, interrupt time, processor queue, context switches, system calls, physical/committed memory, page faults, hard page reads, disk throughput/queue, network throughput, process/thread/handle counts, and per-role process CPU/page-fault deltas.

Windows System and Application logs were checked for display-driver resets, WHEA events, storage timeouts, resource exhaustion, application hangs, and crashes.

5. Controlled no-tracing system sample

This is the strongest system-wide evidence because content tracing was disabled for the entire sample.

Duration: 28 seconds
Samples: 15
Interval: 2 seconds

5.1 Whole-system metrics

| Metric | Min | Median | P95 | Max | Average |
|---|---:|---:|---:|---:|---:|
| Total CPU utilization | 10% | 19% | 36% | 41% | 21.4% |
| DPC time | 0% | 0% | 0% | 5% | 0.33% |
| Interrupt time | 0% | 0% | 1% | 1% | 0.13% |
| Processor queue length | 0 | 1 | 5 | 6 | 1.87 |
| Context switches/sec | 46,226 | 114,663 | 141,315 | 161,374 | 108,884 |
| System calls/sec | 165,027 | 330,917 | 667,911 | 871,299 | 363,274 |
| System processes | 469 | 483 | 490 | 491 | 481.9 |
| System threads | 9,393 | 9,588 | 9,692 | 9,716 | 9,576.9 |
| System handles | 701,245 | 705,320 | 708,257 | 708,308 | 705,576 |
| Available physical memory | 6,723 MB | 7,247 MB | 7,518 MB | 7,528 MB | 7,223 MB |
| Commit in use | 83% | 84% | 85% | 85% | 83.93% |
| Committed memory | 49,914 MB | 50,778 MB | 51,125 MB | 51,173 MB | 50,701 MB |
| Commit limit | 60,009 MB | 60,009 MB | 60,009 MB | 60,009 MB | 60,009 MB |
| Page faults/sec | 97,361 | 257,422 | 559,257 | 834,461 | 323,019 |
| Hard page reads/sec | 0 | 0 | 7 | 128 | 9.87 |
| Pages input/sec | 0 | 0 | 65 | 1,996 | 143.7 |
| Disk throughput | 0 MB/s | 0.43 MB/s | 2.61 MB/s | 14.84 MB/s | 1.61 MB/s |
| Current disk queue | 0 | 0 | 0 | 1 | 0.07 |
| Network throughput | 0.01 MB/s | 0.16 MB/s | 9.65 MB/s | 9.71 MB/s | 2.43 MB/s |

Interpretation:

• CPU was not globally saturated, but queue length reached 6 and context switching exceeded 161,000/sec.
• Commit stayed at 83–85%, leaving limited headroom for process-heavy Electron/Node workloads.
• Page-fault activity was extreme, but hard page reads and disk queue were normally near zero. This identifies predominantly soft page-fault/memory churn, not storage paging.
• DPC and interrupt time were low. A kernel driver interrupt storm is not supported.

5.2 Codex-owned tree during the same controlled sample

| Metric | Min | Median | P95 | Max | Average |
|---|---:|---:|---:|---:|---:|
| Codex-tree processes | 128 | 137 | 141 | 143 | 135.7 |
| Codex-tree threads | 1,449 | 1,548 | 1,591 | 1,606 | 1,526.6 |
| Codex-tree handles | 23,116 | 24,640 | 25,579 | 25,909 | 24,470 |
| Codex-tree working set | 5,750 MB | 6,035 MB | 6,293 MB | 6,296 MB | 6,050 MB |
| Codex-tree private memory | 6,608 MB | 7,007 MB | 7,081 MB | 7,082 MB | 6,917 MB |
| Codex-owned node.exe | 66 | 71 | 73 | 74 | 70.5 |
| Codex-owned cmd.exe | 39 | 42 | 42 | 43 | 41.3 |
| Codex-owned node_repl.exe | 13 | 14 | 14 | 14 | 13.7 |
| MCP-labelled Node processes | 56 | 60 | 60 | 60 | 58.9 |
| Largest repeated MCP fingerprint | 13 copies | 14 | 14 | 14 | 13.7 |

At the medians, the Codex tree represented:

• 28.4% of all system processes: 137 of 483;
• 16.1% of all system threads: 1,548 of 9,588;
• 3.5% of all system handles: 24,640 of 705,320;
• approximately 5.9 GB working set and 6.8 GB private memory.

During only 28 seconds, 11 Codex-tree processes were created and 26 exited. That is 37 lifecycle events, or approximately 1.32 process births/exits per second. The tree was actively shrinking from a recent larger burst, but never fell below 128 processes.

5.3 CPU and page-fault attribution

Raw cumulative deltas were used rather than formatted per-process I/O counters.

| Process role | Average CPU cores | Page faults/sec |
|---|---:|---:|
| Electron main | 2.607 | 316,093 |
| DWM | 0.250 | 22.6 |
| Electron renderer | 0.036 | 3,694 |
| Codex backend | 0.036 | 1,922 |
| Electron utility | approximately 0 | 2,213 |
| MCP Node processes | approximately 0 | 122 |
| Electron GPU | approximately 0 | 14 |
| Code Mode REPL | approximately 0 | 1 |

The total machine averaged approximately 5.14 busy logical cores during the interval (21.4% of 24). Electron main alone averaged 2.607 cores, approximately 51% of all CPU work observed during the sample.

Electron main also accounted for approximately 98% of system page faults: 316,093/sec attributed versus 323,019/sec system average. This strongly localizes the live CPU/memory churn to the Electron main process, even though the retained MCP process population contributes process/thread/handle and commit pressure.

6. Process-avalanche proof

6.1 Peak spot snapshot

| Metric | Peak observed value |
|---|---:|
| Codex-rooted process tree | 322 processes |
| Codex-rooted threads | 3,433 |
| Codex-rooted handles | 56,337 |
| Codex-tree working set | 7.4 GB |
| Codex-tree private memory | 14.7 GB |
| node.exe descendants | 175 |
| cmd.exe descendants | 102 |
| node_repl.exe descendants | 34 |
| MCP-labelled Node descendants | up to 145 |
| All Node processes in system spot sample | 184, 6.65 GB working set, 17.43 GB private memory |

At that moment, the Codex-rooted tree alone accounted for 322 of 656 system processes, approximately 49% of every process on the machine, and 3,433 of 11,109 system threads, approximately 31%.

6.2 Repeating bundle signature

The process counts form a near-integer bundle, which is much stronger evidence than a generic statement that “many Node processes exist.”

Controlled sample:

14 concurrent runtime copies
× (approximately 4 MCP Node + 3 cmd + 1 node_repl)
= approximately 112 helper processes

Observed medians:
60 MCP Node + 42 cmd + 14 node_repl = 116 helper processes
Total Codex-rooted median = 137 processes

The exact cmd.exe and REPL relationships are especially clear:

42 cmd processes = 14 × 3
14 node_repl processes = 14 × 1
56 of 60 MCP Node processes = 14 × 4

Peak snapshot:

35 repeated command fingerprints for each of four MCP process layers
= 140 repeated MCP-labelled Node processes

Expected shell/REPL companions for 35 bundles:
35 × 3 cmd = 105       observed: 102
35 × 1 node_repl = 35  observed: 34

The small deficit is consistent with processes being captured mid-teardown. This repeating 4-Node/3-shell/1-REPL shape is the forensic signature developers should reproduce.

6.3 Simplified anonymous ancestry

Observed parent-chain shapes, with all arguments removed:

codex.exe
├─ node_repl.exe                         × approximately one per runtime
└─ cmd.exe                               × approximately three per runtime
   ├─ node.exe                           MCP-related layer
   ├─ node.exe ← node.exe                MCP-related nested layer
   └─ node.exe ← cmd.exe ← node.exe      MCP-related nested layer

All 145 MCP-labelled Node processes in the largest classified sample traced back to codex.exe.

6.4 Delayed cleanup evidence

In an age snapshot, retained helper processes included:

| Image | 15–30 minutes old | More than 60 minutes old |
|---|---:|---:|
| node.exe | 109 | 9 |
| cmd.exe | 63 | 3 |
| node_repl.exe | 21 | 1 |

The population later declined from the 322-process peak to 128–143 during the controlled sample, while still creating 11 and terminating 26 processes in 28 seconds. This suggests delayed idle cleanup or timeout-based teardown, not prompt ownership-based teardown.

7. Chromium trace proof of UI stalls

7.1 Browser main thread

| Operation | Count | Total time | >16.67 ms | >50 ms | >100 ms | Max |
|---|---:|---:|---:|---:|---:|---:|
| RunMicrotasks | 33,756 | 9,551 ms | 121 | 61 | 43 | 134.4 ms |
| ThreadControllerImpl::RunTask | 37,445 | 11,011 ms | 131 | 69 | 45 | 136.0 ms |
| V8 GC events | 13,953 | 1,747 ms | 15 | 12 | 0 | 71.9 ms |

RunMicrotasks alone occupied approximately 24.9% of the complete trace timeline. Because these are nested trace slices, this percentage must not be summed with parent RunTask time, but it accurately demonstrates sustained microtask activity and repeated long tasks.

7.2 Primary renderer

| Operation | Count | Total time | >16.67 ms | >50 ms | >100 ms | Max |
|---|---:|---:|---:|---:|---:|---:|
| v8.callFunction | 16,572 | 2,950 ms | 15 | 7 | 4 | 189.3 ms |
| FunctionCall | 16,038 | 2,059 ms | 10 | 4 | 2 | 183.3 ms |
| RunMicrotasks | 893 | 1,210 ms | 10 | 4 | 3 | 188.8 ms |
| EventDispatch | 2,362 | 1,049 ms | 4 | 3 | 2 | 190.5 ms |

Seven click events consumed 458.25 ms total:

• three clicks exceeded 50 ms;
• two clicks exceeded 100 ms;
• maximum click dispatch was 190.457 ms;
• another click dispatch was 189.301 ms.

Both long click chains reached the same production bundle location:

app-initial-BBAkuZJK.js:193:124103

Repeated function-call durations at that location were 183.334 ms and 179.951 ms. This is a precise source-map lookup target for the matching desktop build.

7.3 Input comparison

| Input event | Count | P95 | Max | Interpretation |
|---|---:|---:|---:|---|
| click | 7 | 190.5 ms | 190.5 ms | severe application-level input stall |
| scroll | 168 | 8.0 ms | 11.7 ms | below one 60 Hz frame at maximum |
| pointermove | 506 | 0.31 ms | 2.08 ms | not the source of system cursor lag |
| mousemove | 506 | 0.15 ms | 0.41 ms | not the source of system cursor lag |
| pointerdown | 7 | 19.9 ms | 19.9 ms | one missed-frame event |

The pointer/mouse-move handlers themselves are fast. Therefore, the choppy Windows cursor is better explained by global scheduling, Electron main, DWM, commit, and process/thread pressure than by a slow DOM mousemove handler.

7.4 Long-event timeline after startup

The critical application stalls did not occur only at trace initialization:

| Relative trace time | Evidence |
|---:|---|
| 22.22 s | profiler startup blocks several renderer isolates; separate recording overhead |
| 22.69 s | background full array-buffer GC sweep: 185 ms |
| 27.38 s | click dispatch chain: 189 ms; application JS approximately 180 ms |
| 28.32 s | primary-renderer microtasks: 167 ms |
| 28.92 s | background full array-buffer GC sweep: 154 ms |
| 29.53 s | click dispatch chain: 190 ms; application JS approximately 183 ms |
| 29.57–30.17 s | browser-main tasks/microtasks: approximately 134–136 ms |
| 31.29–37.32 s | repeated background array-buffer GC sweeps: approximately 134–229 ms |

This timeline separates content-tracing startup overhead from the later steady-state application stalls.

7.5 GC and memory churn

Background V8.GC_BACKGROUND_FULL_ARRAY_BUFFER_SWEEP events reached 228.8 ms, with repeated sweeps in the 134–194 ms range. The active renderer's own GC max was lower, but the browser process and workers were repeatedly reclaiming memory while the system commit level remained high.

GC is assessed as an amplifier rather than the first trigger. It fits the retained-process/private-memory evidence and the Electron-main page-fault rate.

8. Layout and ResizeObserver feedback

Primary renderer trace totals:

| Operation | Count | Total | P95 | Max |
|---|---:|---:|---:|---:|
| UpdateLayoutTree | 3,088 | 1,444 ms | 4.33 ms | 15.05 ms |
| Document::recalcStyle | 3,087 | 1,364 ms | 4.30 ms | 15.00 ms |
| LocalFrameView::NotifyResizeObservers | 2,931 | 169 ms | 0.07 ms | 7.32 ms |
| Paint | 3,261 | 301 ms | 0.57 ms | 2.68 ms |

Recent log totals:

| Pattern | Count | Peak rate |
|---|---:|---:|
| ResizeObserver loop completed with undelivered notifications | 4,108 | 247/minute |

ResizeObserver callbacks are not individually the longest stalls. The evidence instead shows a persistent size/layout feedback cycle that multiplies style and layout work and floods error handling. It is a strong secondary amplifier and a concrete component-level bug to locate.

9. Background Git, workspace, state, and watch churn

| Sanitized pattern | Count | Peak rate |
|---|---:|---:|
| Git non-zero/failure result | 6,882 | 132/minute |
| No Git remotes found | 6,403 | 132/minute |
| Git origin/ownership resolution warnings | 24 | 4/minute |
| Conversation state not found | 1,310 | 42/minute |
| Completion for unknown conversation | 266 | 15/minute |
| File-watch related entries | 155 | 24/minute |

The two Git counts can overlap on the same log line and must not be added. Their identical peak rate strongly suggests repeated stable-negative polling. Caching/debouncing one negative origin/remote result per workspace should prevent thousands of repeated subprocess and IPC operations.

The conversation-state counts indicate stale or missing state reconciliation. This is a plausible source of the browser-main microtask volume and should be correlated with task activation/deactivation and retained runtime ownership.

10. MCP observability gap

The recent log set contained only 95 MCP-related lines, including 35 warnings. Twenty-three lines contained generic failure/error keywords, but there were no usable lifecycle durations or process ownership fields.

This is inconsistent with the OS-level observation of 14 runtime copies in the controlled sample and approximately 35 copies at peak. Developers currently cannot answer from logs:

• which task owns each runtime;
• whether a runtime is active, idle, closing, or orphaned;
• how many child processes belong to one runtime;
• why a runtime survived for 15–60+ minutes;
• whether shutdown was requested and acknowledged;
• whether a duplicate runtime was intentionally created.

Recommended structured fields:

runtime_instance_hash
owner_task_hash
server_config_hash
spawn_reason
spawn_timestamp
ready_duration_ms
last_request_timestamp
idle_duration_ms
child_process_count
shutdown_requested_timestamp
shutdown_reason
shutdown_duration_ms
forced_kill_boolean

All identifiers can be one-way session-local hashes to preserve privacy.

11. GPU, kernel, disk, and crash evidence

Evidence against common alternative explanations:

• Chromium GPU main trace tasks peaked at 13.6 ms; no GPU task exceeded 16.67 ms.
• Controlled DPC time median and P95 were 0%; average was 0.33%.
• Controlled interrupt time averaged 0.13% and peaked at 1%.
• Disk queue median/P95 was 0; maximum was 1.
• Disk throughput averaged 1.61 MB/s.
• No display-driver reset was recorded during the investigated period.
• No relevant WHEA hardware error, storage timeout, or resource-exhaustion event was found.
• No Codex Application Hang or Application Error event was registered in the preceding week.
• No actual out-of-memory, heap-limit, or allocation-failure event was found in the analyzed logs.

The application remains responsive enough to avoid Windows hang detection while still producing severe frame pacing and scheduling pressure.

12. Content-tracing overhead is separate

Starting content tracing invoked V8 CPU profiler startup in multiple isolates. Observed startup blocks included approximately:

412 ms
424 ms
859 ms
1,112 ms

This explains the additional pause when recording starts. It does not explain normal-use freezes, which were reported without recording and are supported by the controlled no-tracing sample.

13. Causal model

task / Code Mode / MCP activity
        │
        ├─ repeated runtime bundle creation
        │    └─ ~4 node + ~3 cmd + ~1 node_repl per copy
        │
        ├─ delayed teardown / long idle lifetime
        │    └─ hundreds of processes, thousands of threads, high commit
        │
        ├─ browser-main ownership/state reconciliation
        │    └─ microtask storm + soft page-fault churn
        │
        ├─ repeated Git/workspace negative-result polling
        │
        └─ renderer layout/ResizeObserver feedback
             └─ long click JS chains + repeated style/layout work

combined result:
UI frame misses + DWM scheduling competition + choppy system cursor

14. Ranked, falsifiable hypotheses

H1 — P0: runtime lifecycle/teardown defect

Claim: task or Code Mode activity creates one multi-process MCP/REPL bundle per runtime, and bundles survive after useful work is complete.

Prediction: from a clean launch, repeated operations will increase node/cmd/node_repl counts in near 4:3:1 bundles. Ending the owning task will not return counts to baseline within 30 seconds.

Disproof: every operation reuses one bounded runtime, and all task-owned children consistently terminate within 30 seconds.

Confidence: high.

H2 — P0: Electron browser-main state/microtask churn

Claim: the main process continuously reconciles task/runtime/conversation state, producing long microtask queues and memory faults.

Prediction: browser-main profiling without content-tracing startup will show the same ownership/state call chain behind repeated 50–134 ms tasks. Disabling retained runtimes or reducing active tasks will sharply reduce main-process CPU and page faults.

Disproof: main-process CPU/page faults remain unchanged with one task and no MCP/Code Mode runtime.

Confidence: high.

H3 — P1: application click path performs synchronous heavy work

Claim: a click-triggered call in app-initial-BBAkuZJK.js:193:124103 performs synchronous work or drains a large microtask queue.

Prediction: production source-map resolution will identify the same function for both approximately 180 ms calls, and instrumentation around that function will reproduce the click delay.

Disproof: source-map lookup resolves to profiler-only code or an unrelated wrapper with no synchronous work.

Confidence: high.

H4 — P1: ResizeObserver/layout feedback amplifies renderer work

Claim: a component alternates size/state and retriggers observer/layout work faster than the UI stabilizes.

Prediction: component-level observer instrumentation will show repeated notifications without meaningful final-size change; removing or debouncing it will eliminate the 247/minute error bursts and reduce layout counts.

Disproof: observer volume remains but renderer long tasks and errors disappear independently.

Confidence: medium-high as an amplifier.

H5 — P1: repeated Git/workspace probes amplify retained runtimes

Claim: stable-negative Git results are recomputed independently across tasks/runtimes.

Prediction: one workspace with no remote will generate repeated identical negative checks; caching the result per workspace will collapse the 132/minute peak.

Disproof: each log line maps to a genuinely different workspace transition or explicit user action.

Confidence: medium.

15. Developer reproduction protocol

The current machine could not be restarted or have MCP disabled without interrupting the live user session, so a clean A/B baseline was not performed. The following protocol is designed to isolate the trigger safely in development.

Phase A — clean baseline

1. Reboot or terminate all Codex-owned processes.
2. Launch the exact desktop build.
3. Do not open an existing task and do not invoke Code Mode/MCP.
4. Record for 60 seconds:

• Electron main CPU and page faults;
• total Codex child process/thread/handle counts;
• node.exe, cmd.exe, and node_repl.exe counts;
• system commit and context switches.

Phase B — one task, no tool call

1. Open one task.
2. Wait 30 seconds.
3. Record the same metrics.

Expected diagnostic question: does task activation alone create the 4:3:1 bundle?

Phase C — repeated Code Mode/MCP operations

1. Invoke one operation; wait for completion.
2. Repeat 10 times with the same task.
3. Record child-process counts after every operation.

Failure signature:

largest anonymous MCP command fingerprint copy count rises toward N
cmd count rises toward 3 × N
node_repl count rises toward 1 × N
MCP Node count rises toward 4 × N

Phase D — task fan-out

1. Repeat Phase C across 10 tasks.
2. Leave tasks inactive after completion.
3. Observe process ages for 15, 30, and 60 minutes.

Failure signature: linear process growth and helpers remaining after ownership is inactive.

Phase E — teardown test

1. Close/archive the owning tasks.
2. Wait 30 seconds.
3. Verify that all task-owned runtime children exit.
4. Record shutdown request/acknowledgement timing.

Phase F — MCP-disabled differential test

Repeat the same task and click sequence with MCP disabled.

Expected if H1/H2 are correct:

• large reduction in process/thread/handle counts;
• lower Electron-main CPU and page faults;
• lower context-switch rate;
• reduced or absent cursor stutter;
• fewer browser-main long microtasks.

Phase G — UI interaction trace

Use a profiler mode that does not synchronously start all V8 profilers at the beginning of the measured interaction, or discard the initialization interval. Perform seven clicks on the same UI target and inspect:

• EventDispatch;
• FunctionCall;
• v8.callFunction;
• RunMicrotasks;
• production source-map resolution for app-initial-BBAkuZJK.js:193:124103.

16. Acceptance criteria for a fix

• No linear node/cmd/node_repl growth across repeated operations.
• At most one intentionally shared runtime bundle per required scope.
• All task-owned runtime children exit within 30 seconds of task shutdown.
• No orphan runtime older than the documented idle timeout.
• Electron-main idle CPU below 0.1 core on the clean baseline machine.
• Electron-main page-fault rate reduced by at least 90% from the reproduced faulty state.
• No browser-main task above 50 ms during idle interaction.
• No reproduced click dispatch above 50 ms.
• No ResizeObserver loop completed with undelivered notifications burst.
• Git negative results are cached/debounced and do not repeat at triple-digit rates per minute.
• Stable system cursor with multiple completed/inactive tasks.

17. Recommended product instrumentation

Add a privacy-safe diagnostics page or log summary containing:

• active task count;
• active/idle/closing/orphaned runtime count;
• process, thread, and handle counts per runtime;
• runtime owner hash and config hash;
• runtime age, idle age, and teardown duration;
• Electron-main CPU, page faults, event-loop delay, and long-task count;
• renderer long-task count and maximum input dispatch latency;
• ResizeObserver-loop count and layout-update rate;
• Git command count, cache-hit rate, cancellation count, and negative-result reuse;
• process births/exits per minute;
• total Codex private memory and commit contribution.

Recommended automatic warning conditions:

runtime child count exceeds expected bundle size
or runtime remains alive after owner shutdown
or Codex-rooted process count exceeds 100
or browser-main task exceeds 100 ms
or Electron-main CPU exceeds one core for 30 seconds while no task is running
or page faults exceed 100,000/sec for 10 seconds

18. Safe verification commands for developers

The following commands reveal only process-image counts and system metrics on a clean developer machine. They do not read prompts, files, command lines, or endpoints.

Get-Process node,cmd,node_repl,codex,ChatGPT -ErrorAction SilentlyContinue |
  Group-Object ProcessName |
  Select-Object Name,Count

Get-CimInstance Win32_PerfFormattedData_PerfOS_System |
  Select-Object Processes,Threads,ProcessorQueueLength,ContextSwitchesPersec,SystemCallsPersec

Get-CimInstance Win32_PerfFormattedData_PerfOS_Memory |
  Select-Object AvailableMBytes,PercentCommittedBytesInUse,PageFaultsPersec,PageReadsPersec,PagesInputPersec

For exact ownership, use an internal instrumented build that emits session-local hashes. Avoid collecting raw command lines in customer reports.

19. Evidence strength and limitations

Directly observed and repeatable from saved artifacts

• Chromium long-task, input, layout, GC, and browser-main metrics;
• log pattern counts and peak rates;
• trace integrity hash;
• repeating process bundle ratios;
• peak and controlled process/thread/handle/memory snapshots;
• controlled CPU/page-fault/system-counter distributions;
• process births and exits during the controlled interval.

Strong inference

• the 4:3:1 helper bundle is created per task/runtime scope;
• delayed ownership teardown causes the 15–60+ minute population;
• retained runtimes amplify browser-main state reconciliation.

Not yet captured

• pointer-to-presentation latency at the exact moment of the most severe cursor stall;
• a clean restart A/B with MCP enabled versus disabled;
• production source-map resolution for the minified bundle location;
• an internal owner-task mapping for every retained runtime.

A 24-second scheduler-jitter probe did not coincide with a severe global stall; maximum scheduling delay was 14.6 ms. This does not invalidate the reported cursor symptom, but it means the exact cursor frame drop was not captured. A privacy-safe ETW capture synchronized to a visible stall would provide final scheduler-level correlation.

20. Files safe to send

Safe:

• this report;
• codex-freeze-evidence-sanitized.json.

Do not send without separate review and redaction:

• raw Chromium trace;
• raw Codex logs;
• crash dumps;
• full process command lines;
• configuration files.

</details>

<details>
<summary><strong>Machine-readable sanitized metrics (JSON)</strong></summary>

{
  "schema": "codex-desktop-performance-evidence/v1",
  "privacy": {
    "sanitized": true,
    "raw_trace_attached": false,
    "raw_logs_attached": false,
    "excluded": [
      "user_and_machine_names",
      "absolute_paths",
      "workspace_and_repository_names",
      "prompts_and_responses",
      "file_and_terminal_contents",
      "urls_endpoints_tokens_and_environment_values",
      "command_line_arguments",
      "mcp_server_names",
      "task_conversation_process_machine_and_network_identifiers"
    ]
  },
  "environment": {
    "codex_desktop_version": "26.810.6296.0",
    "architecture": "x64",
    "windows_version": "10.0",
    "windows_build": 26200,
    "power_plan": "High performance",
    "cpu": "Intel Core i7-13700F",
    "physical_cores": 16,
    "logical_processors": 24,
    "ram_gb": 31.8,
    "gpu": "NVIDIA GeForce RTX 4070 SUPER",
    "gpu_driver": "32.0.16.1074",
    "gpu_driver_date": "2026-07-02",
    "display_refresh_hz": 239,
    "system_uptime_hours": 47.7,
    "codex_session_uptime_hours": 2.0,
    "configured_mcp_server_sections": 4
  },
  "controlled_no_tracing_sample": {
    "sample_count": 15,
    "interval_seconds": 2,
    "measured_duration_seconds": 28,
    "process_lifecycle": {
      "births_observed": 11,
      "exits_observed": 26,
      "events_per_second": 1.32
    },
    "metrics": {
      "system_process_count": { "min": 469, "median": 483, "p95": 490, "max": 491, "avg": 481.93 },
      "system_thread_count": { "min": 9393, "median": 9588, "p95": 9692, "max": 9716, "avg": 9576.93 },
      "system_handle_count": { "min": 701245, "median": 705320, "p95": 708257, "max": 708308, "avg": 705576.4 },
      "cpu_percent": { "min": 10, "median": 19, "p95": 36, "max": 41, "avg": 21.4 },
      "dpc_percent": { "min": 0, "median": 0, "p95": 0, "max": 5, "avg": 0.33 },
      "interrupt_percent": { "min": 0, "median": 0, "p95": 1, "max": 1, "avg": 0.13 },
      "processor_queue": { "min": 0, "median": 1, "p95": 5, "max": 6, "avg": 1.87 },
      "context_switches_per_sec": { "min": 46226, "median": 114663, "p95": 141315, "max": 161374, "avg": 108884.13 },
      "system_calls_per_sec": { "min": 165027, "median": 330917, "p95": 667911, "max": 871299, "avg": 363274.2 },
      "available_memory_mb": { "min": 6723, "median": 7247, "p95": 7518, "max": 7528, "avg": 7222.93 },
      "committed_memory_percent": { "min": 83, "median": 84, "p95": 85, "max": 85, "avg": 83.93 },
      "committed_memory_mb": { "min": 49914.43, "median": 50778.12, "p95": 51124.93, "max": 51172.72, "avg": 50701.07 },
      "commit_limit_mb": { "min": 60008.79, "median": 60008.79, "p95": 60008.79, "max": 60008.79, "avg": 60008.79 },
      "page_faults_per_sec": { "min": 97361, "median": 257422, "p95": 559257, "max": 834461, "avg": 323018.93 },
      "page_reads_per_sec": { "min": 0, "median": 0, "p95": 7, "max": 128, "avg": 9.87 },
      "pages_input_per_sec": { "min": 0, "median": 0, "p95": 65, "max": 1996, "avg": 143.73 },
      "disk_mb_per_sec": { "min": 0, "median": 0.43, "p95": 2.61, "max": 14.84, "avg": 1.61 },
      "disk_queue": { "min": 0, "median": 0, "p95": 0, "max": 1, "avg": 0.07 },
      "network_mb_per_sec": { "min": 0.01, "median": 0.16, "p95": 9.65, "max": 9.71, "avg": 2.43 },
      "codex_tree_process_count": { "min": 128, "median": 137, "p95": 141, "max": 143, "avg": 135.73 },
      "codex_tree_thread_count": { "min": 1449, "median": 1548, "p95": 1591, "max": 1606, "avg": 1526.6 },
      "codex_tree_handle_count": { "min": 23116, "median": 24640, "p95": 25579, "max": 25909, "avg": 24470.47 },
      "codex_tree_working_set_mb": { "min": 5750.38, "median": 6035.09, "p95": 6292.92, "max": 6296.37, "avg": 6049.71 },
      "codex_tree_private_mb": { "min": 6607.82, "median": 7006.73, "p95": 7081.11, "max": 7081.71, "avg": 6916.86 },
      "codex_node_count": { "min": 66, "median": 71, "p95": 73, "max": 74, "avg": 70.47 },
      "codex_cmd_count": { "min": 39, "median": 42, "p95": 42, "max": 43, "avg": 41.27 },
      "codex_repl_count": { "min": 13, "median": 14, "p95": 14, "max": 14, "avg": 13.73 },
      "mcp_node_count": { "min": 56, "median": 60, "p95": 60, "max": 60, "avg": 58.93 },
      "mcp_anonymous_fingerprint_count": { "min": 6, "median": 6, "p95": 6, "max": 6, "avg": 6 },
      "largest_mcp_fingerprint_copies": { "min": 13, "median": 14, "p95": 14, "max": 14, "avg": 13.73 }
    },
    "process_attribution": {
      "electron_main": { "average_cpu_cores": 2.607, "page_faults_per_sec": 316093.1 },
      "dwm": { "average_cpu_cores": 0.25, "page_faults_per_sec": 22.6 },
      "electron_renderer": { "average_cpu_cores": 0.036, "page_faults_per_sec": 3694.2 },
      "codex_backend": { "average_cpu_cores": 0.036, "page_faults_per_sec": 1921.5 },
      "electron_utility": { "average_cpu_cores": 0, "page_faults_per_sec": 2212.8 },
      "mcp_node": { "average_cpu_cores": 0, "page_faults_per_sec": 122.2 },
      "electron_gpu": { "average_cpu_cores": 0, "page_faults_per_sec": 14.1 },
      "code_mode_repl": { "average_cpu_cores": 0, "page_faults_per_sec": 1.2 }
    },
    "derived": {
      "codex_share_of_system_processes_at_median_percent": 28.4,
      "codex_share_of_system_threads_at_median_percent": 16.1,
      "codex_share_of_system_handles_at_median_percent": 3.5,
      "electron_main_share_of_average_busy_cpu_percent": 50.8,
      "electron_main_share_of_average_system_page_faults_percent": 97.9
    }
  },
  "peak_process_snapshot": {
    "codex_tree_processes": 322,
    "codex_tree_threads": 3433,
    "codex_tree_handles": 56337,
    "codex_tree_working_set_mb": 7422.4,
    "codex_tree_private_mb": 14729.9,
    "node_descendants": 175,
    "cmd_descendants": 102,
    "node_repl_descendants": 34,
    "mcp_labelled_node_descendants_max": 145,
    "system_processes": 656,
    "system_threads": 11109,
    "codex_process_share_percent": 49.1,
    "codex_thread_share_percent": 30.9,
    "all_node_process_spot_sample": {
      "count": 184,
      "working_set_mb": 6651.3,
      "private_mb": 17430.6,
      "maximum_single_process_private_mb": 2733
    },
    "anonymous_mcp_fingerprint_groups": [
      { "label": "F1", "copies": 35 },
      { "label": "F2", "copies": 35 },
      { "label": "F3", "copies": 35 },
      { "label": "F4", "copies": 35 }
    ]
  },
  "process_age_snapshot": {
    "node": { "age_15_to_30_minutes": 109, "age_over_60_minutes": 9 },
    "cmd": { "age_15_to_30_minutes": 63, "age_over_60_minutes": 3 },
    "node_repl": { "age_15_to_30_minutes": 21, "age_over_60_minutes": 1 }
  },
  "trace": {
    "file_size_mib": 453.32,
    "events": 2658005,
    "parse_errors": 2,
    "timeline_ms": 38364.65,
    "desktop_recording_duration_ms": 30959,
    "sha256": "1C66647854070A968F8B3DCE9F37D93B48E7D3FDB89DBCCD21FFCA46617B0D",
    "browser_main": {
      "run_microtasks": { "count": 33756, "total_ms": 9551.35, "over_16_7_ms": 121, "over_50_ms": 61, "over_100_ms": 43, "max_ms": 134.44 },
      "run_task": { "count": 37445, "total_ms": 11010.93, "over_16_7_ms": 131, "over_50_ms": 69, "over_100_ms": 45, "max_ms": 135.953 },
      "v8_gc": { "count": 13953, "total_ms": 1746.76, "over_50_ms": 12, "max_ms": 71.945 }
    },
    "primary_renderer": {
      "v8_call_function": { "count": 16572, "total_ms": 2950.31, "over_16_7_ms": 15, "over_50_ms": 7, "over_100_ms": 4, "max_ms": 189.341 },
      "function_call": { "count": 16038, "total_ms": 2058.78, "over_16_7_ms": 10, "over_50_ms": 4, "over_100_ms": 2, "max_ms": 183.334 },
      "run_microtasks": { "count": 893, "total_ms": 1210, "over_16_7_ms": 10, "over_50_ms": 4, "over_100_ms": 3, "max_ms": 188.781 },
      "event_dispatch": { "count": 2362, "total_ms": 1048.57, "over_16_7_ms": 4, "over_50_ms": 3, "over_100_ms": 2, "max_ms": 190.457 },
      "layout_tree_updates": { "count": 3088, "total_ms": 1444.26, "max_ms": 15.05 },
      "style_recalculations": { "count": 3087, "total_ms": 1363.58, "max_ms": 15.002 },
      "resize_observer_notifications": { "count": 2931, "total_ms": 169.09, "max_ms": 7.323 },
      "paint": { "count": 3261, "total_ms": 301.06, "max_ms": 2.679 }
    },
    "input": {
      "click": { "count": 7, "total_ms": 458.25, "p95_ms": 190.457, "max_ms": 190.457, "over_50_ms": 3, "over_100_ms": 2 },
      "scroll": { "count": 168, "p95_ms": 7.968, "max_ms": 11.746 },
      "pointermove": { "count": 506, "p95_ms": 0.305, "max_ms": 2.079 },
      "mousemove": { "count": 506, "p95_ms": 0.149, "max_ms": 0.408 }
    },
    "application_bundle_target": {
      "asset": "app-initial-BBAkuZJK.js",
      "line": 193,
      "column": 124103,
      "observed_call_durations_ms": [183.334, 179.951]
    },
    "background_full_array_buffer_gc_max_ms": 228.775,
    "gpu_main_task_max_ms": 13.61,
    "profiler_start_overhead_ms": [411.954, 424.244, 859.108, 1111.848]
  },
  "logs": {
    "files": 23,
    "size_mib": 22.8,
    "lines": 62502,
    "severity": { "info": 43182, "warning": 7782, "error": 11538 },
    "patterns": {
      "resize_observer_loop": { "count": 4108, "peak_per_minute": 247 },
      "git_nonzero_or_failure": { "count": 6882, "peak_per_minute": 132 },
      "git_no_remotes": { "count": 6403, "peak_per_minute": 132 },
      "git_origin_or_ownership_warning": { "count": 24, "peak_per_minute": 4 },
      "conversation_state_missing": { "count": 1310, "peak_per_minute": 42 },
      "completion_for_unknown_conversation": { "count": 266, "peak_per_minute": 15 },
      "file_watch_related": { "count": 155, "peak_per_minute": 24 },
      "mcp_related": { "count": 95, "warning_severity": 35, "generic_failure_keyword": 23 }
    },
    "actual_oom_or_heap_limit_errors": 0,
    "process_crashes": 0,
    "unhandled_errors": 0
  },
  "windows_event_checks": {
    "display_driver_reset_found": false,
    "whea_hardware_error_found": false,
    "storage_timeout_found": false,
    "resource_exhaustion_event_found": false,
    "codex_application_hang_last_7_days": 0,
    "codex_application_error_last_7_days": 0
  },
  "scheduler_jitter_probe": {
    "duration_seconds": 24,
    "maximum_delay_ms": 14.62,
    "over_50_ms": 0,
    "severe_cursor_stall_captured": false
  }
}

</details>