Codex VS Code extension silently hangs when VS Code is launched through the packaged Linux desktop entry

What version of the IDE extension are you using?

1.128.0 - 1.129.1

What subscription do you have?

Pro

Which IDE are you using?

VS Code

What platform is your computer?

Ubuntu, KDE Neon, Ubuntu Mint, (Linux 7.0.0-28-generic x86_64 x86_64)

What issue are you seeing?

The Codex VS Code extension frequently fails to finish initialization when Visual Studio Code is launched from the desktop entry supplied by the official Linux VS Code package.

The Codex panel remains stuck on the loading screen. There is no visible error, timeout, retry, or recovery action.

The Codex output stops after:

Activating Codex extension
[CodexMcpConnection] Spawning codex app-server
[IpcRouter] I am the router
[IpcClient] Received broadcast but no handler is configured method=client-status-changed
[CodexMcpConnection] Initialize received id=1

The app-server is spawned and receives the initialization request, but the extension never progresses beyond this point.

Launching the exact same VS Code installation, profile, workspace, and Codex extension from a terminal using:

code .

makes Codex initialize successfully.

What steps can reproduce the bug?

Reproduction steps

1. Install Visual Studio Code from the official Linux package.

1. Install the OpenAI Codex VS Code extension.

1. Launch VS Code from the desktop application menu or a pinned desktop launcher.

1. Open the Codex panel.

1. Observe that the panel remains stuck during initialization.

1. Check the Codex output and observe that it ends after:

``text
[CodexMcpConnection] Initialize received id=1
``

1. Fully close all VS Code processes.

1. Open the same workspace from a terminal:

``bash
code .
``

1. Observe that Codex initializes normally.

Reproduced environments

The issue was independently reproduced on two machines:

Machine 1

OS: Linux Mint 22.1
Architecture: x64
VS Code: 1.128.0
Codex extension: openai.chatgpt 26.715.31925
Bundled Codex CLI: 0.145.0-alpha.18

Machine 2

OS: KDE Neon
Architecture: x64

The problem affected:

• local VS Code workspaces;
• small and empty repositories;
• VS Code Remote-SSH sessions.

On both machines, launching VS Code through the terminal fixed the Codex startup failure.

What is the expected behavior?

Codex should initialize reliably regardless of whether VS Code is launched from a terminal or through the packaged Linux desktop entry.

Even when an upstream VS Code launch-environment difference triggers the problem, Codex should ideally:

• report an actionable initialization error instead of remaining indefinitely on the loading screen;
• time out and offer a retry action;
• log which stage of the app-server initialization handshake failed;
• detect and report relevant differences in the VS Code launch environment.

Actual behavior

The Codex panel remains indefinitely stuck on its loading screen, while the output ends after:

[CodexMcpConnection] Initialize received id=1

No error or recovery option is presented.

Additional information

Identified launch-path difference

The desktop entry supplied by the VS Code Linux package launches the raw executable:

Exec=/usr/share/code/code %F
Exec=/usr/share/code/code --new-window %F

The shell command resolves through the VS Code wrapper:

/usr/bin/code
→ /usr/share/code/bin/code

Creating a user-level desktop-entry override that uses the wrapper fixes the Codex problem immediately:

Exec=/usr/bin/code %F
Exec=/usr/bin/code --new-window %F

After making only this change, Codex starts reliably from the desktop launcher on both machines.

Troubleshooting already performed

Before identifying the launch-path difference, the following were tested without solving the problem:

• reinstalling the Codex extension;
• using a fresh VS Code user-data directory;
• using a fresh extensions directory;
• backing up and recreating the normal VS Code profile;
• clearing VS Code state and caches;
• testing empty directories;
• testing small repositories;
• running the Codex CLI separately;
• manually running the bundled Codex app-server;
• testing local and Remote-SSH workspaces.

The standalone Codex CLI worked normally.

The same VS Code profile, extension, and workspace succeeded or failed depending only on whether VS Code was launched through:

/usr/share/code/code

or:

/usr/bin/code

Related VS Code issue

The underlying launch-path discrepancy has been reported to the VS Code project: https://github.com/microsoft/vscode/issues/326580

Workaround

Override the packaged desktop entry to invoke /usr/bin/code:

mkdir -p ~/.local/share/applications

cp /usr/share/applications/code.desktop \
   ~/.local/share/applications/code.desktop

sed -i \
  's|Exec=/usr/share/code/code |Exec=/usr/bin/code |g' \
  ~/.local/share/applications/code.desktop

update-desktop-database ~/.local/share/applications 2>/dev/null || true

Then remove and re-pin the VS Code launcher, or log out and back in so the desktop environment reloads the user-level entry.