Codex Desktop leaves orphaned agent-browser headless Chrome processes consuming ~400% CPU

No source file or test is named. Start by tracing the Codex task and subprocess lifecycle around the pnpm dlx agent-browser commands, including task completion, failure, interruption, and app restart. Done means the controller and complete headless Chrome process tree are cleaned up, or surviving processes are clearly reported with a cleanup action.

What version of the Codex App are you using (From “About Codex” dialog)?

26.715.31925 (build 5551)

What subscription do you have?

Pro 20x

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

A Codex Desktop task launched agent-browser 0.31.2 through pnpm dlx for browser-based visual assessment. After the task ended, the agent-browser controller and its headless Chrome process tree remained running for nearly three days.

The controller had been reparented to macOS PID 1, indicating that its original parent process had exited. No active client was connected to its session socket, but four Chrome subprocesses were each consuming approximately one full logical CPU core:

Process	CPU
Chrome GPU process	99.5%
Chrome NetworkService	96.5%
Chrome StorageService	96.7%
Chrome renderer	99.4%

Combined CPU usage was approximately 392%.

Before discovering these processes, I had already force-quit Google Chrome, and Chrome was no longer running as a visible application on the Mac. I had also quit and relaunched Codex. The orphaned agent-browser controller and headless Chrome helpers survived both the Chrome force-quit and the Codex restart.

Chrome was launched invisibly with --headless=new and --enable-unsafe-swiftshader, using a temporary agent-browser profile rather than my normal Chrome profile. Google Chrome did not appear in the Force Quit Applications window when the orphaned helpers were discovered.

The originating Codex rollout contained ten commands that opened pages, changed viewport sizes, and captured screenshots. I found no corresponding close, stop, or kill command for the browser session.

This appears to be a task/subprocess lifecycle cleanup issue: an external browser-automation process survived after its controlling Codex process exited and continued consuming substantial CPU indefinitely.

What steps can reproduce the bug?

I have not intentionally reproduced this again because it can leave several CPU-intensive processes running for days, but the observed sequence was:

1. Start a Codex Desktop task that performs browser-based visual assessment.

2. Codex runs commands following this pattern:

   pnpm dlx agent-browser --session <SESSION> open <PUBLIC_URL>
   pnpm dlx agent-browser --session <SESSION> set viewport <WIDTH> <HEIGHT>
   pnpm dlx agent-browser --session <SESSION> screenshot <PATH> --full
   

3. Allow the Codex task to complete or otherwise end without issuing:

   pnpm dlx agent-browser --session <SESSION> close
   

4. The original controlling process exits, but agent-browser remains running and is reparented to PID 1.

5. Force-quit the visible Google Chrome application. Chrome is no longer running as a visible app, but the separate headless agent-browser Chrome process tree remains.

6. Quit and relaunch Codex Desktop. The orphaned controller and Chrome helpers remain running after the app restart.

7. Open Activity Monitor and observe the GPU, renderer, network, and storage helpers each consuming approximately 93–101% CPU.

In this occurrence:

• Codex conversation ID: 019f6979-5d48-7de0-8948-c4f31fe1b7ab
• Originating turn ID: 019f6c08-88b2-72c0-8f0c-078eb93f577e
• Browser session started: July 16, 2026 at approximately 1:52 PM EDT
• Processes were discovered and sampled: July 19, 2026
• agent-browser version: 0.31.2
• Headless Chrome process version: 150.0.7871.116

The rollout contained ten commands for the session but no matching close, stop, or kill command.

What is the expected behavior?

Codex should reliably clean up browser-automation sessions and their complete process trees when:

• A task completes successfully.
• A task fails or is interrupted.
• The controlling process exits.
• The Codex app closes or restarts.

An external tool such as agent-browser should not remain orphaned under PID 1 with a headless Chrome process tree consuming multiple CPU cores.

If automatic cleanup cannot be completed, Codex should report the surviving process and provide a clear cleanup action.

Additional information

Environment:

• macOS 26.5, build 25F71
• Apple silicon, arm64
• Hardware model: MacBookPro18,3
• Codex Desktop: 26.715.31925, build 5551
• Subscription: Pro 20x
• agent-browser: 0.31.2
• Chrome process version: 150.0.7871.116

Live diagnostics captured before termination:

• Five 10-second macOS process stack samples
• Process hierarchy and relevant launch arguments
• PPID 1/orphaning evidence
• Local controller and DevTools endpoints
• Remaining browser targets
• Sanitized originating Codex commands
• Confirmation that no browser-session cleanup command was issued

A sanitized diagnostic archive is retained locally and can be provided privately to OpenAI maintainers upon request. It was sanitized to remove usernames, hostnames, repository names and paths, browser-session names, temporary-profile identifiers, emails, credentials, browser databases, and unrelated Codex content.

After collecting diagnostics, I sent SIGTERM to the orphaned agent-browser controller. All CPU-heavy Chrome children exited successfully. A remaining zero-CPU Chrome crash handler from the same session was then terminated separately. A final process check confirmed that the complete process tree was gone.

Possibly related:

• https://github.com/openai/codex/issues/11090
• https://github.com/openai/codex/issues/16862