high CPU consuming when codex diff render

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

• #13809
• #13717
• #15108

Powered by Codex Action

Not duplicate. no long git diff, only couple lines diff ； no ripgrep (rg) process runaway

Reproducible across VS Code and Cursor

Update with Error Logs:
I've isolated the cause of the 250%+ CPU spike. The extension is entering an infinite error loop when the Diff view is active. It is spamming thousands of requests per minute for an unsupported target.

Log Snippet:
2026-03-23 12:05:15.033 [error] Error fetching errorMessage="open-in-target not supported in extension" errorName=Error url=vscode://codex/open-in-targets

Observed Behavior:

CPU pins at 250-300% immediately when clicking the Codex diff.

CPU drops to normal levels as soon as the Codex dialog/diff is closed or clicked away.

This is happening on macOS (darwin-arm64) with extension version 26.318.11754.

It appears to be an "event storm" similar to what is described in issue #15397. However, in my case, it is not solved even moving back the the primary left side bar. The issue did happen since from the codex extension was removed from the left side with unknown reason after vscode got updated.

The error is not occasional — it is emitted continuously at a very high rate (thousands of times per minute), which strongly suggests a missing guard or retry loop without backoff.

This likely explains both:

• the CPU spike (renderer + extension host busy loop)
• and the broken diff rendering behavior

I'm seeing the same in VSCode on Linux (6.19.8-arch1-1 | AMD AI 7 Pro 350). Codex Ver. 26.318.11754

An active Codex session will peg one thread of the CPU. As noted by issue reporter, this only happens when a session is active; e.g. after a prompt is processed with file changes / diffs. If I go "back" to view all Codex sessions/chats, the CPU immediately drops back to idle, and resuming the problematic session/chat ramps the CPU back to 100%. Restarting VSCode and resuming that same problematic thread no longer pegs the CPU. Notably, in this case the diff hints/links are also absent after restart.

I also began noticing this after the Codex extension was suddenly missing from the left side bar, presumably following an update(?).

I had the same issue. In my case, the problem was resolved by pressing Ctrl + Shift + P and running "Developer: Reload Window".
As @andredunford mentioned, the list of diffs had been removed,

same issue,using higher version than 26.313.41514 can cause this problem.macos 14

Me too

Codex:
26.323.20928

VSCode:

Version: 1.112.0 (Universal)
Commit: 07ff9d6178ede9a1bd12ad3399074d726ebe6e43
Date: 2026-03-17T18:09:23Z (1 wk ago)
Electron: 39.8.0
ElectronBuildId: 13470701
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.3.0

the same issue

The same issue. I have sent a beedback message: fa86b609-5df7-454e-ae09-89b36008fd06

I'm not sure if mine is the same issue.
The Code Helper (Renderer) keeps high cpu even the codex tasks stopped.

Same issue
Linux lt 6.18.8-arch2-1
AMD Ryzen 9 8945HX
90°C

Same issue when Codex applying edits.

Environment:

• VS Code: 1.113.0 (cfbea10c5ffb233ea9177d34726e6056e89913dc, arm64)
• Extension: openai.chatgpt 26.325.31654
• OS: macOS 26.3.1 (Build 25D2128)

Symptoms:

• CPU spikes immediately after Codex finishes updating code
• Code Helper (Renderer) processes ~100–160% CPU
• CPU usage remains high indefinitely until “Developer: Reload Window/Restart Extension Host”

Happens consistently after applying ANY edits.

I can reproduce a very similar issue on Windows 10 with VS Code Remote SSH.

Environment:

• Local OS: Windows 10 x64
• VS Code: 1.113.0
• Remote-SSH: 0.123.2026033115
• Remote host: Ubuntu 20.04
• Codex / OpenAI ChatGPT VS Code extension in a Remote SSH workspace

Observed behavior:

• CPU usage on the local Windows machine becomes high when a Codex session is active.
• It becomes noticeably worse when Codex shows file-edit preview / diff preview.
• Even without actively editing files, keeping the Codex session open can still keep CPU elevated.
• As soon as I exit the Codex session, CPU usage returns to normal.

What is hot:

• The hot processes are local Code.exe renderer processes and node.mojom.NodeService.
• It does not look like the remote Ubuntu host is the direct source of the CPU usage.
• ssh itself is usually not the hot process when this happens.

Relevant logs:

• Repeated PendingMigrationError: navigator is now a global in nodejs
• Repeated warnings like Attempted to report in-progress status for unknown chat session type 'openai-codex'
• I also observed extension host termination / renderer-related instability while the Codex session was active

Important isolation result:

• Disabling Markdown Preview Enhanced did not fix it.
• Remote SSH permission issues were fixed separately and are no longer the blocker.
• Exiting the Codex session immediately drops CPU back to normal, which strongly suggests the Codex session UI / diff

preview / session rendering path is the trigger.

This looks very similar to the high-CPU Codex Diff / session rendering issue described here, but in my case it is
especially visible in a Windows local + Remote SSH to Ubuntu workflow.

This solved temporarily the issue on my linux vscode 1.115.0 + codex 26.5409.20454 deployment:
(credits goes to this solution -- osx only)

set -euo pipefail

EXT_DIR="$HOME/.vscode/extensions"
PATCHED=0
SKIPPED=0
ALREADY=0

find "$EXT_DIR" -maxdepth 1 -type d -name "openai.chatgpt-*" | sort | while read -r dir; do
  ext_js="$dir/out/extension.js"
  version=$(basename "$dir")

  if [[ ! -f "$ext_js" ]]; then
    echo "[$version] extension.js not found, skipping"
    continue
  fi

  # Check if bug is present
  if grep -q '"open-in-targets":async()=>{throw new Error("open-in-target not supported in extension")}' "$ext_js"; then
    echo "[$version] bug detected -- patching..."

    # Backup (only once per version)
    if [[ ! -f "$ext_js.bak" ]]; then
      cp "$ext_js" "$ext_js.bak"
      echo "[$version] backup created: extension.js.bak"
    fi

    sed -i \
      's/"open-in-targets":async()=>{throw new Error("open-in-target not supported in extension")}/"open-in-targets":async()=>({targets:[]})/g' \
      "$ext_js"

    sed -i \
      's/"set-preferred-app":async()=>{throw new Error("open-in-target not supported in extension")}/"set-preferred-app":async()=>({})/g' \
      "$ext_js"

    # Verify
    if grep -q '"open-in-targets":async()=>({targets:\[\]})' "$ext_js"; then
      echo "[$version] patched successfully"
    else
      echo "[$version] patch verification failed -- restoring backup"
      cp "$ext_js.bak" "$ext_js"
    fi

  elif grep -q '"open-in-targets":async()=>({targets:\[\]})' "$ext_js"; then
    echo "[$version] already patched, skipping"
  else
    echo "[$version] open-in-targets pattern not found -- extension structure may have changed"
  fi
done

echo ""
echo "Done. Reload VS Code windows to apply: Cmd+Shift+P -> Developer: Reload Window"

I dug into the installed IDE extension bundle (openai.chatgpt-26.5409.20454-linux-x64) and this looks less like a diff-rendering problem and more like a capability-negotiation bug.

In the extension host, open-in-targets and set-preferred-app are implemented as throwing stubs (Error("open-in-target not supported in extension")). The diff/review webview eagerly queries open-in-targets to decide which “Open in …” actions to show. Because that query fails with no data, TanStack Query still treats it as stale, so staleTime: ONE_MINUTE does not prevent refetches on remount/focus/re-observe. That turns an unsupported feature into repeated bridge calls/logging/retries and high CPU.

Suggested fix:

• return an empty success result for open-in-targets, e.g. { preferredTarget: null, availableTargets: [], targets: [] }
• return a no-op success result for set-preferred-app instead of throwing

@tibo-openai After weeks that the extension is not usable cause heavy CPU load it is time to fix it. The analysis is clear.

It seems to be fixed in Codex vscode extension version 26.415.20818

Adding a bit more from codex's own tracing:

  Root cause: OpenAI Codex/ChatGPT extension (openai.chatgpt)

  What's happening:
  - PID 317291 = Chromium renderer process hosting Codex sidebar webview
  - Webview JS is calling vscode://codex/open-in-targets in tight infinite loop with no backoff
  - Each call hits t_.handleVSCodeRequest → throws "open-in-target not supported in extension" → webview retries immediately
  - 1.8 hours of CPU time in 1.6 hours elapsed = 110% sustained CPU (multi-thread)
  - Generated 34MB of error logs in ~18 seconds of log rotation window
  - Extension version: 26.409.20454 (from nix store)

  Why it's spinning:
  Codex extension webview makes a fetch to vscode://codex/open-in-targets. Extension host throws because this handler doesn't support the "extension" context. Webview gets error response, immediately retries. No exponential backoff,
   no retry limit. Classic busy-wait bug in the extension.