VS Code extension spawns runaway R child processes (R --file=- / R -e) that pin CPU on macOS

What version of the IDE extension are you using?

openai.chatgpt-26.415.20818-darwin-arm64

What subscription do you have?

Plus

Which IDE are you using?

VS Code 1.116.0

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

The VS Code OpenAI/Codex extension intermittently spawns runaway R subprocesses on macOS that pin one or more CPU cores for long periods.

I observed two subprocess patterns:

1. R --no-echo --no-restore -e ...
2. R --no-echo --no-restore --file=-

The second pattern is the more concerning one. Those R --file=- processes are direct children of the Codex app server and appear to be fed multiline R scripts over stdin. They can continue running at ~95-99% CPU for tens of minutes until manually killed.

Representative examples I observed:

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.