›_ Codex Issues
Codex Issues / #30503

Codex Computer Use helper can keep macOS replayd/ReplayKit active and spike CPU while idle

Open 💬 2 comments Opened Jun 29, 2026 by tarek101

Summary

On macOS, the Codex app's Computer Use helper appeared to keep Apple's ReplayKit daemon (/usr/libexec/replayd) active and caused a noticeable CPU spike even though I was not actively using desktop control.

This was observable as replayd repeatedly reappearing in Activity Monitor / process listings and accumulating CPU. Restarting replayd alone did not resolve it because it immediately respawned due to IPC clients. Stopping the Codex Computer Use helper caused the CPU usage to settle.

Environment

  • macOS: 14.8.3 (23J220)
  • Codex.app: 26.623.42026, bundle version 4514
  • Codex bundle id: com.openai.codex
  • Architecture: arm64
  • Chrome was also running, including a video_capture.mojom.VideoCaptureService, but the CPU spike dropped after stopping the Codex Computer Use helper.

What I observed

replayd was the legitimate Apple binary:

/usr/libexec/replayd
Identifier=com.apple.replayd

launchctl showed it being launched by Mach IPC:

gui/501/com.apple.replayd
state = running
program = /usr/libexec/replayd
immediate reason = ipc (mach)
runs = 22
last terminating signal = Killed: 9

Unified logs showed replayd repeatedly accepting connections from these clients:

accepted client connection PID: <ControlCenter>
accepted client connection PID: <Google Chrome>
accepted client connection PID: <Codex.app>
accepted client connection PID: <Codex Computer Use / SkyComputerUseService>

At the moment of the spike, the relevant process snapshot looked like this:

Codex.app                         ~24% CPU
SkyComputerUseService             ~19% CPU
/usr/libexec/replayd                0% CPU immediately after respawn
Google Chrome video_capture helper  0% CPU

After terminating only SkyComputerUseService, the machine settled:

/usr/libexec/replayd     0.0% CPU
Codex.app                ~0.4% CPU
SkyComputerUseService    no longer active

Expected behavior

The Computer Use helper should not keep ReplayKit/replayd active or repeatedly connected when no desktop-control or screen-capture workflow is active. If it needs to start ReplayKit, it should release the session promptly when idle.

Actual behavior

replayd kept respawning because ReplayKit clients were still attached. The Codex Computer Use helper was one of those clients and was consuming significant CPU. Stopping that helper cleared the issue.

Impact

This can show up to users as replayd repeatedly appearing in Activity Monitor and consuming CPU/battery. It is confusing because the visible high-CPU process may be Apple's replayd, while the triggering client appears to be the Codex Computer Use helper.

Notes

I could not read the macOS TCC database due to privacy protections, so I could not list screen-recording permissions from the terminal. The evidence above comes from ps, launchctl print, codesign, and unified logs.

View original on GitHub ↗

2 Comments

lansz · 1 month ago

Additional reproduction / stronger causality confirmation from another machine.

I hit the same failure mode today while the visible Codex session was idle and I was not actively invoking Computer Use / desktop-control features.

Environment:

Timestamp: 2026-07-06 22:37 CST / Asia-Shanghai
macOS: 14.7.8 (23H730)
Architecture: arm64
Codex Desktop: 26.623.101652, bundle version 4674
Bundled Codex CLI: codex-cli 0.142.5
Codex bundle id: com.openai.codex
Computer Use service bundle id: com.openai.sky.CUAService
Computer Use service version: 1.0 (857)
Computer Use service signing: Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2)

Initial process state:

SkyComputerUseService PID 53243, parent Codex PID 52935
SkyComputerUseService elapsed: 03-11:45:37, CPU around 15-17%
/usr/libexec/replayd PID 80191, parent launchd, elapsed around 31m, CPU around 70-78%

The clearest evidence was a STOP / CONT causality test:

before
PID    PPID  STAT  %CPU  ELAPSED       ARGS
53243  52935 S     15.7  03-11:45:37  .../Codex Computer Use.app/.../SkyComputerUseService
80191      1 R     73.4      30:59    /usr/libexec/replayd

after kill -STOP 53243, sleep 5
53243  52935 T      0.0  03-11:45:42  .../SkyComputerUseService
80191      1 S      0.0      31:04    /usr/libexec/replayd

after kill -CONT 53243, sleep 2
53243  52935 S     15.8  03-11:45:44  .../SkyComputerUseService
80191      1 R     71.3      31:06    /usr/libexec/replayd

Then I terminated only the Computer Use service, preserving the main Codex app and app-server:

kill -TERM 53243  # did not exit after 3s
kill -KILL 53243

post cleanup:
Codex.app PID 52935 remained alive
SkyComputerUseService became defunct / no active process matched afterwards
/usr/libexec/replayd CPU: 0.0%

I also reset the helper's screen-capture authorization as a workaround:

tccutil reset ScreenCapture com.openai.sky.CUAService
# Successfully reset ScreenCapture approval status for com.openai.sky.CUAService

10 seconds later:

Codex.app: still running
SkyComputerUseService: no active process found
/usr/libexec/replayd: 0.0% CPU

Other video-capture helpers were present at the time, including Chrome and Claude video_capture.mojom.VideoCaptureService, but they stayed at 0.0% and did not explain the ReplayKit CPU spike. The STOP / CONT test isolated the Codex Computer Use service as the triggering client on this machine.

sample of SkyComputerUseService while it was active showed ReplayKit / ScreenCaptureKit involvement:

Analysis of sampling SkyComputerUseService (pid 53243)
Identifier: com.openai.sky.CUAService
Version: 1.0 (857)
Parent Process: Codex [52935]
Launch Time: 2026-07-03 10:52:11.767 +0800

Relevant frames included:
- RPScreenRecorder recordingDidStopWithError:movieURL:
- RPScreenRecorder updateStateWithActive:error:
- RPScreenRecorder appAudioCaptureStopWithHandler:
- SCStreamManager serverDidDisconnect
- DispatchQueue: com.apple.NSXPCConnection.m-user.com.apple.replayd

This looks like the helper can remain attached to ReplayKit / replayd while idle, and can get into a state where resuming the helper immediately resumes replayd high CPU. A better idle/backoff/release path, or a watchdog that tears down stale capture sessions when no Computer Use turn is active, would likely prevent this.

tangyh008 · 18 hours ago

Additional reproduction — ChatGPT-app-bundled Codex, M1 Pro

Same failure mode reproduced on a different integration path: Codex CLI bundled inside the ChatGPT desktop app (not the standalone Codex Desktop).

Environment

  • macOS arm64, Apple M1 Pro (10 cores), Darwin 24.x
  • ChatGPT desktop app integration: CODEX_CLI_PATH = /Applications/ChatGPT.app/Contents/Resources/codex, bundled codex-cli 0.150.0-alpha.8
  • Computer Use helper: ~/.codex/computer-use/Codex Computer Use.app (com.openai.sky.CUAService)
  • Computer Use plugin computer-use@openai-bundled enabled in ~/.codex/config.toml (notify hook -> SkyComputerUseClient)

Timeline observed (2026-08-26 23:48 – 2026-08-27 02:41, local)

  1. 23:48 — launched ChatGPT app; SkyComputerUseService and Codex app-server started as resident services.
  2. 00:16 — /usr/libexec/replayd began pegging at 67–74% CPU and stayed there for 2.5h with zero Codex sessions running (no thread existed until 01:24).
  3. 01:24–02:32 — two normal Codex sessions ran (both used only exec; no computer-use tool calls). Recording continued throughout and after both sessions ended.
  4. 02:41 — killed SkyComputerUseService only. replayd dropped from 74% to 0.0% immediately and stayed idle. Nothing else was touched.

Causality confirmation: matches the STOP/CONT test in the report above — the Computer Use helper is the driver; replayd saturates only while the helper is alive, even when no desktop-control workflow is active.

Additional observation: ~/.codex/logs_2.sqlite grew to 1.4 GB with log volume exploding ~2x per hour during the incident (668 -> 1092 rows/hour), suggesting an active retry/turn loop (observed codex_core::responses_retry WARNs) alongside the capture loop.

Expected: helper should not hold a ScreenCaptureKit/ReplayKit session (or keep replayd clients attached) when no computer-use task is active; killing the helper is currently the only reliable fix. Happy to provide more diagnostics if helpful.