codex - 💡(How to fix) Fix VS Code extension spawns runaway R child processes (R --file=- / R -e) that pin CPU on macOS

PID    PPID   %CPU   ELAPSED   COMMAND
26097  62427  98.5   09:00     /Library/Frameworks/R.framework/Resources/bin/exec/R --no-echo --no-restore --file=-
26373  62427  98.8   06:55     /Library/Frameworks/R.framework/Resources/bin/exec/R --no-echo --no-restore --file=-
26374  62427  98.8   06:55     /Library/Frameworks/R.framework/Resources/bin/exec/R --no-echo --no-restore --file=-
26462  62427  98.8   06:22     /Library/Frameworks/R.framework/Resources/bin/exec/R --no-echo --no-restore --file=-
and later:

text

PID    PPID   %CPU   ELAPSED   COMMAND
28399  62427  99.3   51:18     /Library/Frameworks/R.framework/Resources/bin/exec/R --no-echo --no-restore --file=-
28400  62427  99.2   51:18     /Library/Frameworks/R.framework/Resources/bin/exec/R --no-echo --no-restore --file=-
Parent process:

text

/Users/usr/.vscode/extensions/openai.chatgpt-26.415.20818-darwin-arm64/bin/macos-aarch64/codex app-server --analytics-default-enabled
So these are not user-started R sessions. They are child processes of the Codex extension.

In the same VS Code session, the Codex extension logs also showed repeated internal errors and cleanup/state issues, including:

local-environments is not supported in the extension
dropping turn-scoped item for unknown turn id
failed shell snapshot deletion
failed MCP process-group cleanup
The practical problem is that Codex leaves behind hot R subprocesses that continue running indefinitely, causing high CPU usage, fan noise, and requiring manual cleanup.

### What steps can reproduce the bug?

I do not yet have a 100% minimal reproduction, but this happens repeatedly in an R-heavy project when using the Codex VS Code extension normally.

Observed pattern:

1. Open an R project in VS Code that uses `renv`.
2. Use the OpenAI/Codex extension in that workspace.
3. Ask Codex to inspect or reason about R scripts, package usage, or data-import functions.
4. After some interaction, check Activity Monitor or inspect processes from the terminal.

In my case, Codex appears to launch helper R subprocesses for inspection. Earlier examples included commands of the form:

```text
R -e "library(zellkonverter); print(args(readH5AD))"
R -e "tf <- utils:::.getHelpFile(help('readH5AD', package='zellkonverter')); cat(tools::Rd2txt(tf))"
R -e "ns <- loadNamespace('zellkonverter'); f <- get('readH5AD', envir=ns); print(formals(f))"
The worse cases are:

text

R --no-echo --no-restore --file=-
These are direct children of the Codex app server and can stay at ~95-99% CPU for long periods.

A useful diagnostic command has been:

bash

ps -axo pid,ppid,%cpu,%mem,etime,time,stat,command | sort -k3 -nr | head -n 20
In every bad case I checked, the hot R jobs were children of the Codex extension app server.

### What is the expected behavior?

Codex may inspect the R environment or packages, but any helper `R` subprocesses should finish quickly or be terminated promptly.

Expected behavior:
- read-only R inspection should complete quickly
- failed internal requests should not leave long-running child processes behind
- Codex should clean up any subprocesses associated with failed/dropped turns
- normal Codex usage in an R-heavy project should not leave background R jobs pegging CPU indefinitely


### Additional information

This report was drafted with help from Codex itself, based on local process inspection and local VS Code/Codex log review.

I am happy to help investigate further and provide more diagnostics, process listings, or logs if useful. However, I have limited understanding of the extension internals, so some of the interpretation here is based on observable process behavior and log patterns rather than deep knowledge of the Codex implementation.

I also locally mitigated part of an earlier issue by making project startup lighter for obvious Codex/VS Code `R -e` probes, but the more serious `R --file=-` cases still appear to be extension-driven.