Codex Desktop leaves headless Playwright/Chrome workers running after session close, causing macOS replayd to stay at ~150% CPU
Open 💬 2 comments Opened Jun 15, 2026 by shm048
What version of the Codex App are you using (From “About Codex” dialog)?
26.609.41114 (3888)
What subscription do you have?
ChatGPT Pro
What platform is your computer?
23.4.0 arm64 arm macOS 14.4.1 (23E224), Apple Silicon
What issue are you seeing?
Codex Desktop visual/browser/computer-use sessions can leave hidden Playwright/Chrome workers running after the session appears closed. These orphaned workers keep macOS replayd active at very high CPU usage, causing rapid battery drain and device heating.
Observed on my machine:
replaydstayed around ~150-160% CPU after Codex sessions were closed in the UI.- Two hidden/headless Chrome processes remained active, using ~20% CPU each.
- Both were children of a Codex node worker.
- The hidden Chrome processes were launched with Playwright/headless flags such as:
--headless--remote-debugging-pipe--no-startup-window--user-data-dir=/var/folders/.../playwright_chromiumdev_profile-*--enable-features=CDPScreenshotNewSurface
The parent worker looked like:
/Applications/Codex.app/Contents/Resources/cua_node/bin/node --experimental-vm-modules ... --session-id ... --working-dir /Users/saurabh/Documents/GitHub/bioq-one-app
### What steps can reproduce the bug?
I do not yet have a minimal deterministic reproduction, but this is the sequence that produced the issue:
1. Start Codex Desktop on macOS.
2. Run one or more Codex sessions that use visual/browser/computer-use behavior, such as visual audit, screenshots, browser inspection, or local app testing.
3. Close or stop those Codex sessions from the UI.
4. Observe macOS Activity Monitor or run:
```bash
ps -axo pid,ppid,pcpu,pmem,stat,comm,args | sort -k3 -nr | head -25
ps -axo pid,ppid,pcpu,pmem,stat,comm,args | grep -i 'replayd\|playwright\|headless\|Codex'
In the failing state, replayd remains at ~150-160% CPU and hidden Playwright/headless Chrome workers remain alive under a Codex node process.
Kill the stale Codex worker and observe replayd return to idle:kill <codex-node-worker-pid> <headless-chrome-child-pids>
# if the parent remains:
kill -9 <codex-node-worker-pid>
In my case, the stale processes were:
Codex node worker: 23090
Headless Chrome children: 23091, 23601
After killing those, replayd dropped from ~156% CPU to 0.0% and stayed idle.
### What is the expected behavior?
**Expected behavior**
```md
When a Codex visual/browser/computer-use session stops, closes, errors, or is no longer visible in the UI, Codex should terminate all related Playwright/headless Chrome workers and release any screen-capture resources.
macOS `replayd` should return to idle automatically without requiring the user to manually find and kill hidden Codex worker processes.
### Additional information
Environment:
- Codex App: 26.609.41114 (3888)
- macOS: 14.4.1 (23E224)
- Platform: `23.4.0 arm64 arm`
- Hardware: Apple Silicon MacBook Air, 8 GB RAM
Important control test:
I initially suspected Wispr Flow because it also has audio/video capture helper processes. However, after killing the stale Codex Playwright workers, I opened Wispr Flow and left it idle. `replayd` remained at `0.0%`. This suggests Wispr was not the stuck cause.
The strong evidence is:
- Before killing stale Codex workers: `replayd` ~150-160% CPU.
- After killing stale Codex Playwright/headless Chrome workers: `replayd` immediately dropped to `0.0%`.
- No macOS thermal warning was recorded, but battery drain and device heat were significant.
Suggested fix:
Codex should track all child Playwright/Chromium processes spawned by visual/browser/computer-use sessions and reliably clean them up when the session ends. It would also help to expose a UI command such as "Stop all browser/computer-use workers" or automatically reap orphaned Playwright workers after a timeout.This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗