Repository navigation
Long-running Codex sessions lead to whole-PC/laptop lag and freezing on Windows #33368
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.707.62119
What subscription do you have?
Pro
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
Long-running Codex Desktop sessions progressively degrade system responsiveness on Windows.
When several threads are allowed to continue working for one or more days, Codex appears to accumulate helper processes, especially codex and node_repl processes. Process count, memory usage, thread count, and OS handles continue growing instead of returning toward baseline after work completes.
The eventual symptoms include:
- Increasing UI latency in Codex.
- Frozen states that last progressively longer.
- Lag affecting the rest of Windows.
- Codex becoming unusable and requiring forced termination.
Terminating Codex immediately releases the accumulated resources and restores responsiveness.
This behavior has occurred on more than one Windows PC, making a machine-specific hardware problem less likely.
What steps can reproduce the bug?
- Open Codex Desktop on Windows.
- Create goals in multiple threads.
- Allow those threads to continue working over an extended period, including normal shell, tool, and REPL activity.
- Keep Codex running continuously for one or more days.
- Periodically inspect the number of
Codex,codex,node_repl, and command-runner processes. - Observe that completed work does not consistently return the helper-process count toward baseline.
- Continue using Codex as the process and handle counts increase.
- Observe progressively worse lag and freezing.
- Terminate Codex and compare resource usage before and after termination.
Using more concurrent threads appears to reproduce the problem faster.
What is the expected behavior?
Helper processes and their associated handles, threads, and memory should be reclaimed when their owning task finishes, is cancelled, or becomes inactive.
Long-running Codex sessions should reach a bounded resource baseline rather than accumulating processes indefinitely.
Codex should also:
- Apply limits to retained helper processes and REPL sessions.
- Clean up stale or orphaned helpers automatically.
- Remain responsive during multi-day sessions.
- Provide a graceful runtime reset if internal helpers become unhealthy.
- Avoid degrading the responsiveness of the rest of the operating system.
Additional information
I collected one-minute telemetry across a 57-day observation window. The public screenshots contain sanitized aggregate data only.
Observed peaks:
- 77,412 telemetry samples.
- 531 Codex-family processes.
- 263
codexhelper processes. - 259 simultaneous
node_replprocesses. - 119,712 OS handles.
- 9,414 threads.
- 12,570 MB private memory.
During one captured severe-lag incident:
Before forced termination:
- 139 Codex-family processes.
- 31,787 handles.
- 2,673 MB private memory.
Within five minutes after termination:
- 4 Codex-family processes.
- 1,833 handles.
- 249 MB private memory.
This suggests a helper-process/session lifecycle defect, handle retention, or missing stale-session cleanup rather than only a conventional JavaScript heap leak.
Activity
github-actions commentedon Jul 15, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
aidawilliam41-ops commentedon Jul 19, 2026
Additional sanitized Windows evidence isolates sustained CPU and memory usage in long-lived code-mode kernels.
Environment:
OpenAI.Codex 26.715.4045.0Observed at 22:18 local time:
node.execode-mode kernels created between 12:55 and 14:00 were still alive more than eight hours later.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:
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.
aidawilliam41-ops commentedon Jul 23, 2026
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:
26.715.10079.00.145.0-alpha.30codex.exeSHA-256:ADF966822B9A04FB3A6E41D7D6A44B60E5C87BEAC6AEBEF5C0B0A2205C8CDF62The 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 → nodebranches were selected only after a repeated identity gate confirmed:11:56:14.912 +03:00;No global process-name scan or blanket process killer was used.
Controlled before/after result
Only the five validated runner roots were stopped. Their children exited naturally. Final readback confirmed
0/15exact 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 → nodebranch, 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:
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:
tree_absent,timeout,termination_failed, orownership_unknown;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.
lwchang018 commentedon Aug 14, 2026
I can reproduce the same issue after a Windows desktop app update on 2026-08-14, and the new build still appears affected.
Environment
26.810.4967.026.803.10989.0151.0.7922.137Reproduction and behavior
Exiting Codex immediately restores normal system responsiveness.
Sanitized diagnostic snapshot
During one affected-session investigation, the Codex-related process family used approximately:
One ChatGPT GPU process alone retained approximately 380–550 MB working set, 7,300 handles, and 200 threads.
The configured
node_replSTDIO MCP uses the OpenAI-providednode_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.lwchang018 commentedon Aug 14, 2026
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.exedesktop process (no--type=rendereror--type=gpu-processargument), not a renderer, GPU process, ornode_repl.exe.Across repeated samples:
This was not equivalent physical-disk or network traffic:
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.logs_2.sqlitefile did not grow during the sample.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_repllifecycle 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.
lwchang018 commentedon Aug 15, 2026
Update: the issue remains reproducible in the Windows desktop package released/installed on 2026-08-15.
Affected build
26.810.6296.0Live affected-state sample
The root
ChatGPT.exedesktop process again showed the same signature previously captured on26.810.4967.0:The overall Codex desktop process family had 9
ChatGPT.exeprocesses using approximately 2.8 GB working set.Control measurements during the same affected state:
node_repl.exe: 8 instances, approximately 78.1 MB combined, with no evidence that they were the active CPU sourceConclusion
The 2026-08-15 build
26.810.6296.0does 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 on26.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_replcomputation.Raw logs, usernames, local paths, and task content are intentionally omitted.
zycck commentedon Aug 15, 2026
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
app-initial-BBAkuZJK.js:193:124103.The 4:3:1 process ratio is particularly strong:
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:
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.
Full sanitized evidence report
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:
node.exe, 102cmd.exe, 34node_repl.exe;RunMicrotasksslices, totaling 9.55 seconds in a 38.36-second timeline;The evidence supports two overlapping P0 candidates:
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:
The report excludes:
The attached machine-readable evidence summary follows the same policy.
3. Test environment
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
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
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:
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
Interpretation:
5.2 Codex-owned tree during the same controlled sample
node.execmd.exenode_repl.exeAt the medians, the Codex tree represented:
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.
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
node.exedescendantscmd.exedescendantsnode_repl.exedescendantsAt 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:
The exact
cmd.exeand REPL relationships are especially clear:Peak snapshot:
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:
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:
node.execmd.exenode_repl.exeThe 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
RunMicrotasksThreadControllerImpl::RunTaskRunMicrotasksalone occupied approximately 24.9% of the complete trace timeline. Because these are nested trace slices, this percentage must not be summed with parentRunTasktime, but it accurately demonstrates sustained microtask activity and repeated long tasks.7.2 Primary renderer
v8.callFunctionFunctionCallRunMicrotasksEventDispatchSeven click events consumed 458.25 ms total:
Both long click chains reached the same production bundle location:
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
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
mousemovehandler.7.4 Long-event timeline after startup
The critical application stalls did not occur only at trace initialization:
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_SWEEPevents 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:
UpdateLayoutTreeDocument::recalcStyleLocalFrameView::NotifyResizeObserversPaintRecent log totals:
ResizeObserver loop completed with undelivered notificationsResizeObserver 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
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:
Recommended structured fields:
All identifiers can be one-way session-local hashes to preserve privacy.
11. GPU, kernel, disk, and crash evidence
Evidence against common alternative explanations:
Application HangorApplication Errorevent was registered in the preceding week.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:
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
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_replcounts 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:124103performs 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
node.exe,cmd.exe, andnode_repl.execounts;Phase B — one task, no tool call
Expected diagnostic question: does task activation alone create the 4:3:1 bundle?
Phase C — repeated Code Mode/MCP operations
Failure signature:
Phase D — task fan-out
Failure signature: linear process growth and helpers remaining after ownership is inactive.
Phase E — teardown test
Phase F — MCP-disabled differential test
Repeat the same task and click sequence with MCP disabled.
Expected if H1/H2 are correct:
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;app-initial-BBAkuZJK.js:193:124103.16. Acceptance criteria for a fix
node/cmd/node_replgrowth across repeated operations.ResizeObserver loop completed with undelivered notificationsburst.17. Recommended product instrumentation
Add a privacy-safe diagnostics page or log summary containing:
Recommended automatic warning conditions:
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.
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
Strong inference
Not yet captured
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:
codex-freeze-evidence-sanitized.json.Do not send without separate review and redaction:
Machine-readable sanitized metrics (JSON)
{ "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 } }