[extension] Runaway rg processes + high CPU/RAM after extension update

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

• #13583
• #13343

Powered by Codex Action

Thanks for linking #13583 and #13343.

I reviewed both. They are related by symptoms (thread-stream-state-changed / streaming warnings), but this appears to be a different failure mode in our case, so I believe this should stay open as related-not-duplicate.

Our environment:

• Linux (Ubuntu 24.04), VS Code, latest OpenAI/Codex extension at time of report
• Regression started immediately after extension update

What is different here:

• Runaway rg spawning from the extension host with cwd=/home/<redacted-user> (outside the active workspace scope)
• Sustained high CPU across most cores
• RAM growth over time until VS Code exits/crashes
• Repeated logs during spikes:
• thread-stream-state-changed ... no handler
• local-environments is not supported in the extension
• database is locked
• Codex process is not available

Temporary mitigation:

• A local guard script that throttles/kills the runaway rg pattern prevents RAM exhaustion, but this is only a workaround.

Happy to provide redacted logs/process snapshots if useful.

Do you suspect (or even better, have evidence) that this is a regression? If so, do you happen to know the exact version when this started? Can you confirm by rolling back to the previous version and verifying that it doesn't happen there?

Thanks for the follow-up. Sharing technical details with all user/project identifiers redacted.

Environment

• OS: Ubuntu 24.04 (x64)
• VS Code: Stable (Snap build)
• Extension versions observed/tested: openai.chatgpt-26.5304.20706, openai.chatgpt-26.304.20706 (and release channel package 0.4.79 installed)

Observed failure mode

• Continuous runaway rg spawning from VS Code utility process.
• Typical process chain:

code --type=utility --utility-sub-type=node.mojom.NodeService -> codex app-server -> rg

• Repeated rg command:

rg --files --hidden --case-sensitive --no-require-git --glob-case-insensitive --ignore-file-case-insensitive --no-ignore-parent --follow --no-config

• Critical signal: many rg run with cwd=$HOME (outside active workspace scope), causing large scans and sustained CPU.
• Impact: high CPU across many cores; memory pressure grows over time; VS Code can become unstable/crash without mitigation.

Repeated logs during spikes

• local-environments is not supported in the extension
• Received broadcast but no handler is configured method=thread-stream-state-changed
• sometimes: open-in-target not supported in extension
• frequent slow sqlite write warnings from app-server (sqlx::query: slow statement ...)

Regression status

• The issue became noticeable immediately after updating to 26.5304.20706.
• Rolling back to 26.304.20706 still reproduces in our environment.
• Important caveat: stale extension-host processes from previous versions can remain alive and contaminate rollback tests.

We are now validating with clean A/B runs (single extension version active + fresh VS Code start).

Current mitigation (workaround only)

• A guard process that kills only VS Code rg with cwd=$HOME keeps the machine stable.
• In active incidents we measured >600 killed rg/minute, confirming sustained runaway spawning.

Thanks for the follow-up. We do suspect a regression.

What we observed:

• After updating to openai.chatgpt-26.304.20706 (VS Code extension), we intermittently see runaway rg spawns and high CPU/RAM.
• The spawned command pattern is:
• rg --files --hidden --no-ignore-parent --follow --no-config
• parent process: node.mojom.NodeService
• working directory falls back to $HOME instead of the opened workspace.
• Around spikes, logs show repeated PromptFilesLocator failures for agent/prompt patterns under file:///home/<user> and repeated stream-state warnings.

Why we think this is extension-side:

• Issue became noticeable again right after extension update.
• Behavior is tied to VS Code utility/exthost process tree and Codex extension logs.

Mitigation/workaround (local):

• Constrain/disable global chat file location scans to avoid $HOME-wide probing.
• Force workspace-based cwd in local extension runtime (temporary patch).
• Emergency guard script to stop runaway rg bursts while investigating.

Current status:

• Stable after mitigations, but this is not a root-cause fix.

Suggested fix direction:

• Ensure all locator/search invocations are workspace-scoped by default.
• Avoid $HOME fallback for locator scans.
• Gracefully handle unsupported local-environment capabilities without retry loops.

I also see the same since switching to Codex VS Code extension. I notice because the system (M2 Max Mac) grinds to a halt, and then I am sure to find dozens/hundreds of "rg" processes in Activity Manager:

<img width="1512" height="887" alt="Image" src="https://github.com/user-attachments/assets/3a6e82c2-7048-41b4-a638-fa136d8645f1" />

Potentially related: https://github.com/openai/codex/issues/10846

I checked again because this keeps slowing my PC down to a halt. @etraut-openai would be great if this could be looked into – it's making it almost impossible to use the Codex VS Code extension for me, which seems to be the culprit here. Is this the right repo to report issues for that?

I analyzed it with Codex (in the terminal) and it recommended disabling Codex (in VS Code) 🫠
Codex says it's literally a skill issue – there's hundreds of rg processes running against the "openai-curated" skills.

• Ran ps -axo pid=,ppid=,pgid=,pcpu=,pmem=,etime=,state=,comm=,command= | rg
  │ '(^|/)rg( |$)|[[:space:]]rg[[:space:]]'
  └ 27360  1787   686   2.2  0.0    00:39 R    /Applications/Vi /Applications/V
    isual Studio
    … +691 lines
    28572 28568 28568   0.0  0.0    00:00 S    rg               rg (^|/)rg( |$)|
    [[:space:]]rg[[:space:]]

────────────────────────────────────────────────────────────────────────────────

• It’s live, and this time the source is clearer:

  639 rg processes are running right now, almost all parented by VS Code plugin
  host PID 1787. That process is: /Applications/Visual Studio Code.app/.../Code Helper (Plugin) with parent 686
  (Visual Studio Code).

  The important part is the actual rg command line. They’re all searching paths
  like:

  - /Users/herbst/.codex/plugins/cache/openai-curated/github/.../skills/.../
    assets/github.png
  - /Users/herbst/.codex/plugins/cache/openai-curated/github/.../skills/.../
    assets/github-small.svg
  - /Users/herbst/.codex/plugins/cache/openai-curated/github/.../skills/.../
    assets/yeet.png

  So this is not generic workspace search. It’s VS Code repeatedly spawning
  ripgrep against the Codex/OpenAI plugin skill cache under ~/.codex/plugins/
  cache/....

  The strongest reading is:

  - Top-level app: VS Code
  - Immediate launcher: Code Helper (Plugin) PID 1787
  - Likely feature/extension involved: the OpenAI/Codex VS Code extension path,
    because the targets are all in the Codex plugin cache

...and this sounds like a reasonable analysis too:

 What the live rg commands were doing was:

  rg --files --hidden --case-sensitive --no-require-git \
    -g **//Users/herbst/.codex/plugins/cache/.../skills/.../assets/github.png \
    -g !**/.git ... --no-ignore --follow --no-config --no-ignore-global

  Why that is expensive:

  - --files means “walk the filesystem and enumerate files”, not “open this one known file”.
  - --hidden --no-ignore --no-ignore-global --follow means it scans basically everything, including hidden dirs
    and symlinked trees.
  - The target is a single exact asset file like github.png or yeet-small.svg, but it’s being passed as a glob
    pattern.
  - That glob is malformed for this use: **//Users/herbst/... is effectively treating an absolute path as a
    recursive workspace search pattern.
  - So instead of reading one known file from ~/.codex/plugins/cache/..., VS Code is launching hundreds of full
    file-tree walks and filtering afterward.

EDIT: I got it patched locally, and so far the issue doesn't happen anymore. Codex said:

• The extension builds absolute icon paths for curated skills under ~/.codex/plugins/cache/openai-curated/

github/<revision>/....

• logs show repeated reads against old revisions like b4940fd0... and a371d3ce..., while the current files

on disk are under fb0a1837....

• errors are in Library/Application Support/Code/logs/20260410T100609/window2/exthost/openai.chatgpt/

Codex.log

• The icon-path construction logic is in .vscode/extensions/openai.chatgpt-26.406.31014-darwin-arm64/out/

extension.js, in the recommended-skills code, which returns absolute asset paths under a
specific cache revision.

• The bad fallback is also in .vscode/extensions/openai.chatgpt-26.406.31014-darwin-arm64/out/extension.js:

read-file-binary tries a direct absolute-path read, then wrongly falls back to workspace.findFiles("**/
<absolute path>").

Potential cause:

1. Skill metadata hands the UI an absolute icon path tied to a specific cache revision.
2. The cache refreshes or rotates to a new revision hash.
3. The old absolute path becomes invalid.
4. read-file-binary fails the direct read.
5. It then does the broken findFiles fallback, which spawns many ripgrep instances.

@pc-oai I see you closed this, great! But what PR/change fixed it, could you link that here? Thank you!