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

[juandediosyanez]

What version of the Codex App are you using (From “About Codex” dialog)?

26.5304.20706

What subscription do you have?

ChatGPT PRO

What platform is your computer?

Linux 6.17.0-14-generic x86_64 x86_64; VS Code 1.110.0 (Snap); Ubuntu 24.04.4 LTS

What issue are you seeing?

Summary

After updating the Codex VS Code extension to 26.5304.20706, VS Code intermittently spawns runaway ripgrep (rg) processes and CPU usage becomes very high. In severe cases, RAM usage grows and VS Code can crash.

Environment

• VS Code: 1.110.0 (Snap)
• Codex extension: 26.5304.20706
• OS: Ubuntu 24.04.4 LTS
• Kernel: Linux 6.17.0-14-generic x86_64

Reproduction steps

1. Open VS Code with a normal workspace (~10k files).
2. Work normally with the Codex extension enabled.
3. After some time, CPU rises and many rg processes appear.

Observed behavior

• Repeated rg command launched by extension-host:
  /snap/code/.../@vscode/ripgrep/bin/rg --files --hidden --case-sensitive --no-require-git --glob-case-insensitive --ignore-file-case-insensitive --no-ignore-parent --follow --no-config
• cwd for those rg processes is /home/<user>.
• Frequent log errors:
  • local-environments is not supported in the extension
  • Received broadcast but no handler is configured method=thread-stream-state-changed
  • database is locked
  • Codex process errored: Codex process is not available
• CPU remains high and VS Code becomes unstable.

Expected behavior

No runaway rg spawning and stable CPU/RAM usage during normal usage.

Temporary workaround

A local guard that kills runaway rg children reduces RAM blowups, but this does not fix the root cause.

What steps can reproduce the bug?

1. Start VS Code with the Codex extension enabled (version 26.5304.20706).
2. Open a regular workspace (about ~10k files, mixed source/docs/logs).
3. Open Codex chat panel and use it normally (ask questions, read files, continue conversation).
4. Wait a few minutes; in some sessions it happens quickly after reconnect/reload.
5. Observe process list:
   • many rg child processes are spawned by VS Code extension-host
   • command pattern:
     /snap/code/.../@vscode/ripgrep/bin/rg --files --hidden --case-sensitive --no-require-git --glob-case-insensitive --ignore-file-case-insensitive --no-ignore-parent --follow --no-config
   • cwd observed for runaway scans: /home/<user>
6. CPU rises significantly; RAM can grow until VS Code becomes unstable or crashes.

Related recurring errors seen in extension logs:

• local-environments is not supported in the extension
• Received broadcast but no handler is configured method=thread-stream-state-changed
• database is locked
• Codex process is not available

What is the expected behavior?

• Codex extension should not spawn runaway ripgrep scans outside the intended workspace scope.
• CPU and RAM usage should remain stable during normal Codex usage.
• No repeated extension-host error loops.
• VS Code should remain responsive and not crash.

Additional information

Environment:

• VS Code: 1.110.0 (Snap)
• Codex extension: 26.5304.20706
• OS: Ubuntu 24.04.4 LTS
• Kernel: Linux 6.17.0-14-generic x86_64

Temporary mitigation used locally:

• A guard process that kills runaway rg children reduced RAM blowups, but this is only a workaround and not a root-cause fix.

Notes:

• The issue became noticeable again after updating the OpenAI/Codex extension.
• This report intentionally redacts all personal/project identifiers.

[github-actions]

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

• VS Code extension 0.4.79: repeated thread-stream-state-changed warnings, missing tool-step streaming #13583
• [VS Code extension][Windows 11] Streaming UI stalls/no token-by-token updates; repeated thread-stream-state-changed broadcasts with no handler #13343

Powered by Codex Action

[juandediosyanez]

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.

[etraut-openai]

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?

[juandediosyanez]

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.

[juandediosyanez]

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.