openai
Codex spawning multiple node processes that block computer
What version of Codex is running?
codex-cli 0.3.0
Which model were you using?
codex-mini-latest
What platform is your computer?
Darwin 24.4.0 x86_64 i386
What steps can reproduce the bug?
Run codex with a complex typescript codebase on full-auto and give long and complex tasks
What is the expected behavior?
Runs smoothly and doesn't break computer. Seems like it's not closing processes. This happens often in the workflow and it's not just a one-off.
What do you see instead?
See image
Additional information
My hypothesis is that it has something to do with https://github.com/openai/codex/pull/1590. Will try to look into that today.
Out of curiosity, did you install via
npmas opposed tobrew?
I installed it with brew.
@MauScheff hmm, OK, then #1590 is not likely the right fix. I do have one other hypothesis...
But to confirm: do you believe Codex was invoking node as part of its work?
@MauScheff while I don't believe https://github.com/openai/codex/pull/1626 will fix your issue since your screenshots appear to be on macOS, can you tell me what those node commands were (i.e., the full argument list)? Or more importantly, were they long-running commands (like tsc --watch) or something else? Is the PPID 1 (the init process) because they were reparented after codex exited?
I do believe they were spawned by codex, but it could be something else, as that problem happened during a workflow when I was mostly using codex --full-auto on VSCode to work with TypeScript, but it could be something else like VSCode itself (or an extension), and I may have occasionally used Copilot Chat (and that caused the issue) but I used it sparingly (eg. 5% of the time) and I remember having to reset my computer and killing those processes, and this happening again a few times. I was working with a complex typescript codebase, and I always allow codex to go outside the sandbox, so it may have ran some commands. All I have is the screenshots I added from when that happened. It could have been that vscode was running tsc --watch but I'm not sure. I can see that all processes have the same number of threads, this may suggest whomever spawned them was the same actor. I just verified that if I open the same project on VSCode, there is no node process that just runs: eg. a background long running tsc --watch (and I wasn't doing that). The one thing I probably did inadvertently was having multiple running instances of codex (but only one operating at the time).
@MauScheff thanks for the incredibly detailed report!
I'm going to start paying more attention to this and have some ideas on how to create the equivalent to #1626 in a way that works on Mac.
Ahh I see, interesting, I understand what happened now, makes sense. I don't know how you would get around it though. Seems like an OS level problem were parent processes can be killed and the children keep running as if they're disconnected.
I think I’ve encountered a phenomenon similar to what’s described in this issue.
$ sw_vers
ProductName: macOS
ProductVersion: 15.6
BuildVersion: 24G84
$ codex --version
codex-cli 0.19.0
Steps to reproduce:
- Run
npm run testvia Codex CLI. In my case, this script runsvitest run. - While tests are running, check processes via
ps aux | grep node. You can see multiplenode (vitest N)processes. - Exit Codex.
- Run
ps aux | grep nodeagain — somevitestprocesses are still alive.
Example output while Codex was running:
USER PID %CPU %MEM ... COMMAND
... node (vitest 1)
... node (vitest 4)
... node (vitest 7)
... /path/to/esbuild --service=...
... codex-aarch64-apple-darwin --full-auto
After Codex exit (still running):
USER PID %CPU %MEM ... COMMAND
... node (vitest 7)
... node (vitest 3)
... node (vitest 4)
From what I can tell, the remaining processes are child processes spawned by vitest itself. This does not happen when running npm run test directly in a regular terminal — only when run inside Codex.
Additional information for https://github.com/openai/codex/issues/1570#issuecomment-3169766722
- This does not reproduce when running inside a sandboxed environment.
- However, if sandbox execution is denied with
EPERM, it may fall back to direct execution (instead of privilege escalation), and in that case the issue reproduces. - The remaining processes disappear automatically after some time (around 5 minutes).
@ishikawa I still need to review https://github.com/openai/codex/pull/1852, which may help (/cc @md-oai)
- Codex v0.22.0 on macOS 15.6
- Running npm run test (vitest) leaves orphaned node (vitest N) processes
- Processes remain after Codex exits or times out
- Each orphaned process consumes ~100% CPU
Temporary workaround until fixed (at least for my own vitest processes):
Add to your shell profile (.zshrc or .bashrc)
alias codex-cleanup='pkill -f "node.*vitest"'
Looks like what needs to be implemented is some kind of process group management, similar to how shells handle job control with setpgid() and to kill the entire process group on exit.
@mettamatt I was able to instruct my agent to run codex-cleanup after every test run it initiates :D
I think the original issue reported here is no longer relevant because the CLI has been completely rewritten in Rust since then. Some of the other issues that were reported in this thread may still be an issue today, but it's hard to say. If you're seeing a similar issue, please open a new bug report and provide repro steps.
