›_ Codex Issues
Codex Issues / #16320

High CPU usage triggered by rendering file/code links in chat; confirmed `open-in-target` failure loop in extension

Open 💬 3 comments Opened Mar 31, 2026 by ralikwen

What version of the IDE extension are you using?

openai.chatgpt-26.325.31654-win32-x64

What subscription do you have?

ChatGPT Plus

Which IDE are you using?

VS Code

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

Rendering file/code links in the Codex chat webview triggers a high-frequency error loop in the extension host:

open-in-target not supported in extension
vscode://codex/open-in-targets

This causes sustained CPU usage until the chat/webview is closed or reloaded. No user interaction (click) is required.

Minimal Trigger

Rendering a Codex response that contains file/code links is sufficient to trigger the issue. No click is required.

Environment

OS: Windows 11
VS Code: [fill in version]
Extension: openai.chatgpt-26.325.31654-win32-x64

Reproduction Steps

  1. Open VS Code with the Codex/ChatGPT extension enabled.
  2. Open the chat panel.
  3. Ask Codex for a response that includes clickable file/code references.
  4. Wait for the response to render.
  5. Optional: click one of the rendered file/code links.

Expected Behavior

Rendering the response should not cause persistent CPU usage.
File/code links should open the referenced file and location inside VS Code.
No repeated error logging should occur.

Actual Behavior

As soon as a response containing file/code links is rendered, CPU rises and remains elevated.
No click is required to trigger the issue.
Closing or reloading the affected chat/webview drops CPU back down.

Observed but not yet log-confirmed in the captured logs:

Clicking one of the rendered file/code links appears to open an external browser instead of opening the file/location inside VS Code.

Confirmed Log Evidence

The extension logs show repeated failures on the same internal route and stack.

Frequency:

~600-800 failures per second (based on timestamps and counts)

Confirmed sessions:

  1. C:\Users\***\AppData\Roaming\Code\logs\20260331T112536\window1\exthost\openai.chatgpt\Codex.log
  • 680 occurrences
  • First occurrence: 2026-03-31 12:35:58.964
  • Last occurrence: 2026-03-31 12:35:59.977
  1. C:\Users\***\AppData\Roaming\Code\logs\20260330T152658\window1\exthost\openai.chatgpt\Codex.log
  • 797 occurrences
  • First occurrence: 2026-03-31 00:07:15.808
  • Last occurrence: 2026-03-31 00:07:17.074

Representative log entry:

[error] Error fetching errorMessage="open-in-target not supported in extension"
url=vscode://codex/open-in-targets

Representative stack from the same entries:

Error: open-in-target not supported in extension
	 at open-in-targets (...\openai.chatgpt-26.325.31654-win32-x64\out\extension.js:255:22561)
	 at W_.handleVSCodeRequest (...\openai.chatgpt-26.325.31654-win32-x64\out\extension.js:255:27618)
	 at Qw.fetch (...\openai.chatgpt-26.325.31654-win32-x64\out\extension.js:214:1973)
	 at t.handleMessage (...\openai.chatgpt-26.325.31654-win32-x64\out\extension.js:230:65930)

What Is Confirmed vs Not Confirmed

Confirmed from logs:

  1. The extension repeatedly attempts vscode://codex/open-in-targets.
  2. The extension reports open-in-target not supported in extension hundreds of times in rapid succession.
  3. The failure occurs across at least two sessions.
  4. The failure originates in the extension host path.

Observed locally but not confirmed from logs captured here:

  1. Clicking a rendered file/code link appears to open an external browser instead of opening in VS Code.
  2. A malformed URL transformation such as https://file+.vscode-resource.vscode-cdn.net/... may be involved.

Process Evidence

Secondary window renderer dropped from about 7% to 0% when the affected chat/webview state was closed.
Main window dropped from about 3% to about 1%.

This points to the chat/webview renderer plus extension-host interaction rather than general workspace indexing.

Hypothesis (based on logs)

The strongest current theory is that rendering file/code links causes the webview or chat bridge to invoke an open-in-targets path that is not supported in the extension runtime, and that failure is retried or repeatedly re-requested fast enough to create sustained CPU usage and log spam.

That would explain both:

  1. CPU increase during rendering without requiring a click.
  2. Repeated extension-host errors on the same internal route.

Developer Triage Notes

Most relevant log file:

C:\Users\***\AppData\Roaming\Code\logs\<session>\window1\exthost\openai.chatgpt\Codex.log

Most relevant stack frames:

  1. open-in-targets
  2. handleVSCodeRequest
  3. fetch
  4. handleMessage

Most relevant URL/route:

vscode://codex/open-in-targets

Useful questions for investigation:

  1. Why is open-in-targets being invoked during render rather than only on explicit click?
  2. Why is unsupported behavior producing a repeated fetch/error loop instead of a single handled failure?
  3. Is the webview link renderer requesting open-target metadata continuously for every rendered file/code reference?
  4. Is there an environment split where this route is supported in one host path but not in the VS Code extension path?

Workarounds

Avoid responses that include clickable file/code links.
Reload the window.
Close the affected chat tab or webview.
Disable the extension.

Optional Additional Evidence To Add If Reproduced Again

If the browser-opening behavior is reproduced again, include:

  1. The exact clicked link text.
  2. The exact URL opened externally.
  3. A screenshot of the browser URL bar if it shows a transformed URL such as https://file+.vscode-resource.vscode-cdn.net/....

That would help confirm whether the click path and the render-time open-in-targets failure are the same underlying bug or two related bugs.

What steps can reproduce the bug?

Reproduction Steps

  1. Open VS Code with the Codex/ChatGPT extension enabled.
  2. Open the chat panel.
  3. Ask Codex for a response that includes clickable file/code references.
  4. Wait for the response to render.
  5. Optional: click one of the rendered file/code links.

What is the expected behavior?

_No response_

Additional information

Rendering the response should not cause persistent CPU usage.
File/code links should open the referenced file and location inside VS Code.
No repeated error logging should occur.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗