›_ Codex Issues
Codex Issues / #16862

Codex CLI leaves orphaned arm64 processes at ~80–100% CPU when terminal window is closed without /exit

Open 💬 7 comments Opened Apr 5, 2026 by R-9000
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

v0.118.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.4

What platform is your computer?

macOS on Apple Silicon (Mac mini M4 Pro, 64 GB RAM)

What terminal emulator and version are you using (if applicable)?

Terminal.app on macOS

What issue are you seeing?

When I close a terminal window while Codex CLI is still running (without typing /exit first), Codex leaves behind orphaned processes that continue consuming roughly 80–100% CPU each.

Important details:

  • This does not happen just by starting codex
  • This happens specifically when the terminal window is closed while Codex is still active
  • If I run /exit first and only then close the terminal window, the problem does not occur
  • I can reproduce this in ~, in other folders, and even in a completely empty folder
  • The Codex Mac app does not show this behavior for me
  • Killing the hot leftover codex processes in Activity Monitor usually has no visible negative effect on the actual Codex usage, which strongly suggests these are orphaned/stuck processes rather than the real active session

Observed behavior in Activity Monitor:

  • with 13 leftover Codex processes: about 85% CPU per process
  • with 14 leftover Codex processes: about 81% CPU per process

Architecture checks show this is not a Rosetta/x64 case:

  • node is arm64
  • the hot Codex binary is codex-darwin-arm64
  • the shell is running natively on arm64

What steps can reproduce the bug?

  1. Open a new terminal window
  2. Run codex
  3. Do not type /exit
  4. Close the terminal window directly while Codex is still running
  5. Open Activity Monitor
  6. Observe leftover codex processes consuming around 80–100% CPU each

Control case:

  1. Open a new terminal window
  2. Run codex
  3. Type /exit
  4. Close the terminal window
  5. No orphaned hot processes remain

I can reproduce this:

  • in ~
  • in other directories
  • in a completely empty directory

Additional architecture evidence:

file "$(which node)" output:
[redacted-user-path]/bin/node: Mach-O 64-bit executable arm64

arch output:
arm64

sysctl -in sysctl.proc_translated output:
0

Example hot process:
.../node_modules/@openai/codex/node_modules/@openai/codex-darwin-arm64/vendor/aarch64-apple-darwin/codex/codex

Thread id: not captured

What is the expected behavior?

Closing the terminal window while Codex CLI is running should either:

  • terminate Codex cleanly, or
  • handle terminal/TTY shutdown gracefully

It should not leave behind orphaned codex processes that continue consuming close to one full CPU core each.

Additional information

This looks like a terminal-close / TTY / orphaned-process lifecycle bug rather than a workspace-specific issue.

Key points:

  • not specific to ~
  • reproducible in an empty directory
  • does not happen if /exit is used first
  • native Apple Silicon / arm64
  • leftover hot processes can often be killed without affecting real usage

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #15379
  • #16256

Powered by Codex Action

R-9000 · 3 months ago

Thanks — I checked the suggestions.

#16256 is unrelated: that is an MCP sub-agent / suspended-session issue, not a terminal-close orphaned CPU-spin issue.

#15379 is broader and only partially overlaps. My report is specifically about:

  • closing Terminal.app while Codex is still running
  • no issue if /exit is used first
  • reproducible in an empty directory
  • native arm64 Codex binary
  • orphaned leftover processes consuming ~80–100% CPU each

Because the trigger, scope, and observed behavior are materially different, I do not think this should be auto-treated as a duplicate of those reports.

etraut-openai contributor · 3 months ago

I'm not able to repro the issue as reported.

How are you closing the Terminal.app? Do you just click on the close box in the window? If so, do you see this dialog?

<img width="248" height="230" alt="Image" src="https://github.com/user-attachments/assets/a3db36c6-ffeb-4e0b-bc2a-3eb5e83dee0d" />

lanhel · 3 months ago

Using v0.118.0 open codex in an empty directory. Then close the terminal window. This will show the terminate alert. Click terminate. In Activity Monitor the codex instance will not close and the %CPU will go to 100%.

<img width="266" height="242" alt="Image" src="https://github.com/user-attachments/assets/f9b99fb9-c0c5-4beb-a0a5-e776ce4f10a8" />

System Info: MacBook Pro with Tahoe 26.3.1

Note that this also was happening with v0.117.0.

etraut-openai contributor · 3 months ago

I'm not able to repro. There must be some other factors that are necessary to make this occur.

I'm using Tahoe 26.4, but it's unlikely that matters.

Are you killing it during MCP startup? I wonder if you have an MCP server installed that Codex is trying to start but fails.

What other non-default configuration options do you have in your config.toml? If you temporarily switch to a default (empty) configuration, are you still able to repro?

R-9000 · 3 months ago

I narrowed this down step by step...

My original repro was in my normal setup, where closing the Terminal window showed the macOS terminate dialog with additional processes such as:

  • Chromium
  • node (3)
  • codex
  • 127.0.0.1:9222
  • chrome-devtools-mcp (2)

So initially, MCP / Chromium was a plausible factor.

I then reduced the setup further:

  • cleared my .codex config
  • repeated the repro
  • in that case, the macOS terminate dialog only listed:
  • codex
  • node

After that, I tested an even cleaner minimal repro:

System:

  • macOS 26.4 (25E246)
  • Codex CLI v0.118.0
  • native Apple Silicon / arm64

Fresh repro steps:

  1. Launch a fresh Terminal.app instance
  2. Run:

mkdir -p /tmp/codex-repro-empty
cd /tmp/codex-repro-empty
mkdir -p /tmp/codex-home-clean
CODEX_HOME=/tmp/codex-home-clean codex

  1. Run /mcp

In that fresh setup:

  • /mcp showed no MCP tools available
  • the close dialog only listed:
  • codex
  • node

After confirming Terminate, I still got a leftover hot Codex process.

Concrete example from that fresh repro:

  • PID: 36460
  • TTY: ??
  • CPU: 98.4%
  • binary: native codex-darwin-arm64

So the issue still reproduces after progressively stripping the setup down to:

  • fresh Terminal.app instance
  • fresh CODEX_HOME
  • empty directory
  • no MCP tools configured in that session

That makes it look like a core terminal-close / process-shutdown bug in Codex CLI rather than something specific to Chrome DevTools MCP.

!Image
<img src="https://github.com/user-attachments/assets/ca337bdc-5156-4179-b6a5-0bfc47e0aef6" width="350" alt="Terminal"><img src="https://github.com/user-attachments/assets/218c7fef-835c-4c50-a232-b5f26a659c45" width="350" alt="Terminal">

lanhel · 3 months ago

I did an empty config.toml and ran from an empty directory.

I also ran list_mcp_resources and list_mcp_resource_templates in an instance and there were none.

I am going to update to Tahoe 26.4 and see what happens.

UPDATE: I have updated to Tahoe 26.4 so that is not the issue.