›_ Codex Issues
Codex Issues / #35659

Codex Computer Use leaves ScreenCaptureKit stream running at ~56 FPS, causing high WindowServer GPU on macOS

Open 💬 5 comments Opened Jul 27, 2026 by vickyzer027-hash

Summary

Codex Desktop's bundled Computer Use runtime can leave a ScreenCaptureKit stream running after the Computer Use interaction/session has ended. The stale stream continued producing roughly 55–56 frames per second with no consumer, driving WindowServer to about 50–60% CPU and 59% GPU on macOS.

Fully quitting Codex clears the condition. Closing the target application or ending the visible Computer Use interaction does not.

Environment

  • macOS 26.5.2 (25F84), arm64
  • Codex Desktop 26.721.41059 (build 5848)
  • Bundled Codex CLI 0.146.0-alpha.3.1
  • Computer Use runtime 26.721.1000502 (build 1000502)
  • One active external display: 2560×1440 at 100 Hz

Reproduction

  1. Launch Codex Desktop on macOS.
  2. Use the bundled Computer Use capability to inspect/control another macOS app.
  3. Finish the interaction and fully quit the target app.
  4. Stop making Computer Use calls and inspect Activity Monitor using All Processes, sorted by % GPU.
  5. Inspect the running Computer Use helpers and recent replayd / SkyComputerUseService unified logs.

The issue may be easier to reproduce after more than one Codex task/thread has loaded Computer Use. In this reproduction, two SkyComputerUseClient event-stream mcp processes remained connected to one SkyComputerUseService.

Actual behavior

After the target app had fully exited:

  • No target-app process remained.
  • WindowServer was approximately 56.6% CPU and 59.4% GPU.
  • Codex's own GPU process was below 1% GPU at the same time.
  • One SkyComputerUseService and two SkyComputerUseClient event-stream mcp processes remained.
  • replayd still reported an active capture session attributed to the SkyComputerUseService PID.

Representative sanitized log evidence:

FigVideoQueueGMStats: 334 frames enqueued in the last 6 seconds
recent frames: enqueued: 335, displayed: 0, evicted: 335
SCCaptureSession setupHealthMonitor: screenframeCount=279
fetchShareableContent... currentProcessID=<SkyComputerUseService PID>

The screenframeCount samples were taken five seconds apart, corresponding to roughly 55–56 captured frames per second. Frames continued to be generated even when none were displayed and all were evicted.

Resetting the current node_repl Computer Use client stopped one capture stream, but another stream continued at the same rate. WindowServer remained around 46–49% CPU during a separate 10-second top sample with no UI automation calls being made.

No GPU reset, GPU hang, AGX timeout, GPU fault, or Metal fault appeared in the same one-hour log window.

Expected behavior

When the Computer Use tool call/turn/session ends and there is no active consumer:

  • its ScreenCaptureKit stream should stop;
  • stale per-thread MCP clients should be disconnected or reaped;
  • SkyComputerUseService should not continue producing frames that are immediately evicted;
  • WindowServer GPU usage should return to its normal idle level.

Workaround

Fully quit Codex with Cmd-Q, wait for SkyComputerUseService and SkyComputerUseClient to exit, and reopen Codex.

Suggested fix

  • Tie each ScreenCaptureKit stream to an explicit consumer/session lifetime.
  • Stop and invalidate the stream when the last consumer disconnects or a turn ends.
  • Add an idle guard: if frames are continuously evicted with no displayed/consumed frames, tear down the stream.
  • Reap stale event-stream mcp clients and prevent multiple abandoned clients from keeping capture alive.
  • Add a regression test that verifies helper count and active ScreenCaptureKit streams return to baseline after a Computer Use turn ends.

Related issue

  • #29157 tracks leaked SkyComputerUseClient turn-ended notifier helpers. This report is related but distinct: the leaked clients here are event-stream mcp clients and an active ScreenCaptureKit stream continues rendering at high frame rate, causing sustained WindowServer GPU load.

View original on GitHub ↗

5 Comments

galligan · 22 days ago

Confirming this on a newer build, with per-client CPU measurements that may help isolate the stranded stream.

Environment

| | Reported in issue | This report |
|---|---|---|
| Codex Desktop | 26.721.41059 (5848) | 26.727.51351 (6119) |
| Bundled CLI | 0.146.0-alpha.3.1 | 0.146.0-alpha.9.2 |
| CU runtime | 26.721.1000502 | 26.727.1000550 |
| macOS | 26.5.2 (25F84) | 26.6 (25G70) |
| Hardware | — | M2 Ultra, 128 GB |
| Display | 1× 2560×1440 @ 100 Hz | 1× 6016×3384 Retina 6K |

Different display configuration, same symptom — so this does not appear to be specific to a particular refresh rate or external-display setup.

Observed

SkyComputerUseClient event-stream mcp clients accumulate against a single SkyComputerUseService and are never reaped. The original report saw 2; this machine currently has 10, all children of the ChatGPT.app codex ... app-server (pid uptime 21h39m).

SkyComputerUseService: 1 instance
SkyComputerUseClient event-stream mcp: 10 instances

The part that may be diagnostic: per-client CPU is constant

Each leaked client burns a near-identical fraction of a core, independent of how long it has been alive:

| CPU time | Elapsed | Ratio |
|---|---|---|
| 10:10.75 | 12:47:56 | 1.33% |
| 10:09.45 | 12:47:49 | 1.32% |
| 10:08.29 | 12:47:44 | 1.32% |
| 10:06.94 | 12:42:05 | 1.33% |
| 7:35.56 | 9:52:52 | 1.28% |
| 7:34.06 | 9:52:55 | 1.28% |
| 2:20.56 | 3:27:18 | 1.13% |
| 0:19.52 | 30:40 | 1.06% |
| 0:06.41 | 10:58 | 0.97% |
| 0:03.60 | 5:58 | 1.01% |

The ratio does not decay as a client ages. That is consistent with each client holding its own fixed-rate periodic work item (e.g. a capture stream at a constant FPS) that continues after the consumer is gone, rather than a one-time cost or a slow drain. Practical consequence: total CPU cost scales linearly with the leak count — currently ~12% of one core, continuously, at 10 clients.

WindowServer on this machine has been sitting at 34–61% CPU with 2.2–3.9 GB resident across several days of observation, which is consistent with the mechanism described in this issue, though I have not independently confirmed the ScreenCaptureKit attribution here.

Accumulation rate from a clean boot

Measured across a reboot boundary, so this is a clean-start rate rather than a long-tail accumulation:

  • ~0.45 event-stream clients/hour (10 clients at 21h39m app-server uptime)
  • 9 → 10 clients observed within a single hour of normal use
  • Prior boot (uptime 3d21h) reached 161 total app-server children before a restart

On the prior boot the accumulation was heavy enough to push a 128 GB machine into sustained memory pressure: swap file grew 3 GB → 4 GB with 3.2 GB in use, compressor at 19 GB, ~1.1 GB free. After reboot: swap 0, compressor 2.4 GB, 10 GB free. The reboot resolved it and the accumulation immediately began again, which points at lifecycle rather than any single runaway process.

Distinguishing this from the turn-ended leak

This machine has zero PPID=1 orphans, so this is a distinct path from #26293 and #29157, even though it is the same binary:

  • #26293 / #29157 — SkyComputerUseClient turn-ended helpers, reparented to launchd (PPID=1)
  • This issue — SkyComputerUseClient event-stream mcp, retained as live children of the app-server, each holding ongoing periodic work

Both leak paths are reachable from the same install: the turn-ended notifier is configured via notify = [".../SkyComputerUseClient", "turn-ended"] in config.toml, while the event-stream clients are spawned by the app-server itself.

Related

  • #25744 — umbrella report for macOS Computer Use / MCP helper accumulation; notes "dozens of live SkyComputerUseClient mcp processes" alongside node_repl and codex app-server --listen stdio:// helpers
  • #30408 — MCP per-thread processes never cleaned up
  • #26293, #29157 — the turn-ended / PPID=1 variant described above

Quitting and relaunching Codex clears the condition, matching the original report. Ending the Computer Use interaction does not.

galligan · 22 days ago

Follow-up to my measurements above, with what I think is a sharper statement of the lifecycle bug.

Each leaked event-stream client is 1:1 with a thread, and is stranded exactly when that thread goes idle.

How to recover the mapping

The client processes carry no thread identity — args are byte-identical (SkyComputerUseClient event-stream mcp), and a 1-hour-old client is structurally indistinguishable from a 14-hour-old one (both: 7 threads, 3 pipes, 2 systm sockets, same fd profile). state_5.sqlite and logs_2.sqlite have no column linking a thread to an OS pid.

But the mapping is recoverable by timestamp. For each client, compute spawn_time = now - etime and compare against recency_at in the threads table:

pid      spawn_time   matched thread.recency_at   Δ
17673    02:05:50     02:05:50                    0s
17950    02:05:57     02:05:57                    0s
18277    02:06:02     02:06:02                    0s
24727    02:11:41     02:11:41                    0s
21788    05:00:51     05:00:51                    0s
21990    05:00:54     05:00:54                    0s
1544     14:42:48     14:42:48                    0s
8597     14:47:48     14:47:48                    0s
82577    14:23:06     — no match —
15983    14:54:24     — no match —
56809    15:58:14     — no match —
57181    15:58:33     — no match —

Δ is exactly 0 for 8 of 12 clients, across spawn times spanning 14 hours. That is not coincidental alignment.

The four non-matches are the confirming case

Every unmatched client belongs to a thread whose recency_at advanced past the client's spawn time:

client spawned 14:23:06  ->  thread recency 14:42:48  (+1182s)
client spawned 14:54:24  ->  thread recency 15:08:15  (+831s)
client spawned 15:58:14  ->  thread recency 16:00:38  (+144s)
client spawned 15:58:33  ->  thread recency 16:00:38  (+125s)

So the correlation holds in both directions:

  • spawn_time == thread.recency_at — the thread's last activity is frozen at the moment its client spawned. Nothing has happened in that thread since. The client is stranded, yet it keeps its periodic work item alive indefinitely (~1.0–1.33% of a core, per my earlier comment).
  • no match — the thread has been used since its client spawned, so recency_at has moved on. The client is live.

Why this may be useful for a fix

This narrows the bug from "helper processes accumulate" to something more specific: the client is spawned per-thread and is never torn down when its thread goes idle or is navigated away from. The teardown appears to be missing at exactly the point where a thread stops being the active one — not at app quit (which does clean up), and not at turn end (which is the separate #26293 / #29157 path).

It also means the leak count is bounded by "number of threads that have ever used Computer Use this app session," which matches what I observe: the clients accumulate roughly in step with distinct threads used, not with turns taken.

Side note for anyone working around this locally

The same correlation makes a safe local reaper possible without guessing: only kill clients whose spawn time matches an idle thread's recency_at. Live threads fail to match automatically, so they are protected without needing to be identified. (Read the DB with ?immutable=1 to avoid lock contention with the running app.) This is a workaround, not a fix — the teardown still belongs in the app.

galligan · 22 days ago

Correction to my previous comment. I suggested there that the spawn-time correlation "makes a safe local reaper possible." I tested that, and it does not work. Retracting it, and the reason why turns out to be more informative than the workaround would have been.

The experiment

Killed one stranded client with SIGTERM — pid 17673, idle 14h42m, matched to a thread whose recency_at had been frozen since the client spawned.

The kill itself was clean: the process exited, SkyComputerUseService stayed up, the app-server stayed up, and the other ten clients were untouched. No collateral.

But the app-server spawned a replacement within about one second, with the same parent. Watched for three minutes afterward:

16:48:53  clients=11   replacement cputime=0:00.48
16:49:38  clients=11   replacement cputime=0:00.87
16:50:39  clients=11   replacement cputime=0:01.43
16:51:39  clients=11   replacement cputime=0:02.01

Client count held at 11 → 11. The replacement accumulated 1.53 CPU-seconds over 166 seconds — 0.92% of a core, sustained — matching the 1.28–1.33% of the client it replaced. It is not a transient reconnect that idles out.

There is also a second-order problem. The replacement's spawn time is now, so it no longer coincides with any idle thread's recency_at:

PID      SPAWN      AGE      THREAD-ID   TITLE
15332    16:48:08   00:21    —           <no match — classified live>

So killing a stranded client converts it into one the correlation can never identify again. Applying the approach across all stranded clients would yield the same number of processes, the same CPU cost, and no way to detect them afterward. Do not use the workaround I described.

What this says about the bug

These clients are supervised, not merely leaked. The app-server maintains one per thread and restarts it when it dies.

That reframes the defect. It is not "teardown is missing at process exit" — teardown is being actively defeated by a supervisor that is doing what it was designed to do. The missing step is earlier: the thread is never deregistered as needing a Computer Use client when it goes idle, so the supervisor correctly keeps honoring a registration that should have been released.

That also explains cleanly why quitting the app is the only thing that clears the condition, as the original report noted: quitting destroys the supervisor along with the whole registration set. Nothing short of that can win, because anything short of that is arguing with a supervisor.

I do not think there is a viable user-side mitigation, and I would discourage anyone from building one — a scheduled reaper would burn CPU killing processes that immediately return.

Everything in my earlier comments still holds: the 1:1 spawn-time ↔ recency_at correlation (Δ = 0 across 8 of 12 clients), the per-client CPU cost, and the accumulation rate. The correlation remains a good way to observe which thread owns which client. It is just not a basis for acting on them.

yangwuan55 · 22 days ago

Cross-link to #37062 — fresh WindowServer SIGABRT repro on 26.6 + cua_node dyld loop

Adding a same-day observation from #37062 (the dedicated crash issue): on macOS 26.6 (25G72, xnu 12377.161.13~4), the leak described here is reproducibly crashing WindowServer via WSCaptureCreateIOSurfaceMachPortForWindowList → WSIOSurfaceDebugTallyAndAbort. Kernel emits "IOSurface count of 65024 approaching limit of 65536" twice in the minutes before the abort.

A separate, possibly-related failure mode: 21 node-*.ips for cua_node (all coalesce to slice 87fbc746-7d47-3fd8-b0a3-97018cbf954b) abort in dyld4::prepare after 7.2 s, suggesting the ChatGPT.app bundle's dyld pointer cannot resolve to a real libnode location. May be downstream of the WindowServer abort; may be independent — root cause not isolated yet.

Full stacks, PIDs, kernel timeline, workaround, frequency, and suggested fixes are in #37062. Happy to fold any of it back into this thread instead if a maintainer prefers.

coalitionName: ai.lark-channel-bridge.bot.codex on the cua_node crashes confirms these were spawned from a Codex session.

asin76-svg · 19 days ago

Confirming this on a newer Computer Use runtime and through a non-Codex-Desktop frontend that launches the official Codex app-server.

Environment

  • macOS 26.6.1 (25G76), Apple Silicon
  • Paseo Desktop 0.3.0-beta.4
  • Codex CLI 0.146.1, launched by Paseo as codex app-server --enable goals
  • ChatGPT Desktop 26.803.41515 (build 6321)
  • Computer Use runtime 26.804.1000633 (build 1000633)
  • @oai/sky 0.6.2

Observation

After a Paseo-managed Codex agent used Computer Use for a UI inspection and returned to idle, there were no further Computer Use tool calls, but the capture pipeline remained active:

  • SkyComputerUseService stayed at about 23.8% CPU.
  • replayd remained active.
  • A 90-second unified-log window contained 356 frame decode/queue-stat matches.
  • Individual ScreenCaptureKit/CoreMedia queues reported roughly 320–330 frames every 6 seconds (about 53–55 FPS), with zero displayed and frames continuously evicted.
  • Multiple SkyComputerUseClient event-stream mcp processes remained as children of Codex app-server processes.
  • There were no SkyComputerUseClient turn-ended helpers, so this is the event-stream mcp path described here, not the separate notifier leak in #26293.

macOS continued to treat the display as actively captured after the agent turn ended. One secondary effect was that macOS suppressed desktop notification banners while its global “show notifications when mirroring or sharing the display” option was disabled.

Lifecycle detail

Paseo keeps the Codex app-server and its node_repl kernel alive between turns. In @oai/sky 0.6.2, the macOS path lazily caches a singleton Mac client/native-pipe transport, but the exported Sky API and Mac client declarations expose no close, dispose, or disconnect operation. The bundled Computer Use skill also defines no end-of-task cleanup.

In an earlier controlled check, resetting and then terminating the initiating node_repl and its session-specific Computer Use client did not stop frame decoding in the shared service. This is consistent with the supervised-client behavior already documented in this issue: killing an individual client is not a durable workaround.

Recovery check

I sent a normal SIGTERM only to SkyComputerUseService; Paseo, Codex app-server, and all unrelated processes remained running. After 15 seconds:

  • SkyComputerUseService was absent;
  • replayd was at 0.0% CPU;
  • there were zero new frame-decode/queue-stat matches.

This clears the stale state but is only a reset, not a lifecycle fix. The service can start again on the next Computer Use request.

This reproduction suggests the regression test should also cover app-server consumers outside Codex Desktop: after the last Computer Use request/turn becomes idle, the ScreenCaptureKit stream and per-thread event-stream registration should be released even when the app-server itself remains alive. A supported macOS transport/session teardown API would also make frontend-level cleanup possible.