Codex VS Code extension hangs in WSL while stuck on “Installing”

Open 💬 2 comments Opened Jul 14, 2026 by zlkzlk123
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the IDE extension are you using?

26.707.41301 (WSL/Ubuntu remote extension); 26.707.71524 (Windows local extension)

What subscription do you have?

ChatGPT Plus

Which IDE are you using?

Visual Studio Code 1.128.0, connected to WSL: Ubuntu

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

The Codex VS Code extension hangs in a WSL: Ubuntu remote window.

The Windows-local extension updated to 26.707.71524, but the WSL remote extension remained on 26.707.41301 and the Extensions view showed it as “Installing”. Opening the Codex panel caused it to stay loading, and after a short time the entire VS Code window became unresponsive.

Git functionality in VS Code continued to work normally; the issue was isolated to the Codex extension/panel.

Relevant log excerpts (user path redacted):

PendingMigrationError: navigator is now a global in nodejs
.../.vscode-server/extensions/openai.chatgpt-26.707.41301-linux-x64/out/extension.js

CodeWindow: detected unresponsive
CodeWindow unresponsive samples: ...

What steps can reproduce the bug?

  1. On Windows x64, open Visual Studio Code 1.128.0 connected to a WSL: Ubuntu workspace.
  2. Have the local Codex extension update to 26.707.71524 while the WSL remote extension remains on 26.707.41301.
  3. Open the Codex panel or open the Codex extension details page.
  4. The WSL extension remains in an “Installing” state.
  5. Wait briefly; the Codex panel keeps loading and then the entire VS Code window becomes unresponsive.

Retrying the installation did not resolve the problem.

What is the expected behavior?

The WSL remote extension should update successfully, or show a recoverable installation error. Opening the Codex panel should not block the VS Code renderer or make the entire editor window unresponsive.

Additional information

The issue appears related to a stale WSL remote extension version and compatibility with the current VS Code runtime. No project source code or personal data is needed to reproduce the symptom.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

  • #32109

Powered by Codex Action

zlkzlk123 · 1 month ago
Potential duplicates detected. Please review them and close your issue if it is a duplicate. * [[Regression] Codex Remote SSH WebView spins Code Helper (Renderer) at 100-200%; Service Worker reset is temporary #32109](https://github.com/openai/codex/issues/32109) _Powered by Codex Action_

I reviewed #32109 and do not believe this is the same issue.

My report is on a WSL: Ubuntu remote window, not Remote SSH. The primary failure occurs while the WSL-side Codex extension is stuck in an “Installing” state with a version mismatch:

  • Windows-local extension: 26.707.71524
  • WSL remote extension: 26.707.41301

Before VS Code becomes unresponsive, the remote extension host logs:

PendingMigrationError: navigator is now a global in nodejs
.../.vscode-server/extensions/openai.chatgpt-26.707.41301-linux-x64/out/extension.js

The observed symptom is that opening Codex leaves the panel loading and then makes the whole VS Code window unresponsive. I did not observe the Remote SSH WebView/Code Helper CPU behavior described in #32109, and I have not tested a service-worker reset as a workaround.

If maintainers believe these share an underlying renderer issue, I’m happy to provide additional diagnostics.