Codex hangs when VS Code is launched from the desktop launcher (/usr/share/code/code) but works when started with code (/usr/bin/code) on Linux Mint

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

• #33060
• #33059
• #32530

Powered by Codex Action

I reproduced the same issue on Ubuntu with the Codex VS Code extension
26.707.71524-linux-x64.

Symptoms

When VS Code is launched from the desktop/pinned launcher, Codex remains on
the loading logo indefinitely. In some cases, the VS Code renderer also
crashes with:

The window terminated unexpectedly
reason: 'crashed'
code: '135'

The desktop launcher was executing:

/usr/share/code/code

When VS Code is launched from a terminal using:

code .

Codex loads successfully.

code resolves through:

/usr/bin/code -> /usr/share/code/bin/code

Diagnostics

The Codex CLI works normally and is authenticated using ChatGPT.

In both the successful and failed cases, the Codex app-server starts and
receives initialization:

Activating Codex extension
Spawning codex app-server
Initialize received id=1

In the failed desktop-launch case, VS Code Developer Tools reports failures
loading local Codex webview assets:

Unable to preload CSS
Failed to load resource: net::ERR_FAILED
potential listener LEAK detected

The stack repeatedly contains:

doReadFileStream
readFileStream
loadResource

Affected URLs use the local VS Code webview resource scheme:

https://file+.vscode-resource.vscode-cdn.net/.../
openai.chatgpt-26.707.71524-linux-x64/webview/assets/...

The failed Codex log never reaches:

React root render requested
[startup][renderer] app routes mounted

When launched using code ., it does reach those messages and the Codex UI
loads successfully.

The following warnings occur in both the successful and failed runs, so they
do not appear to be the direct cause:

failed to refresh available models:
timeout waiting for child process to exit

failed to load recommended plugins:
EOF while parsing a value

Controls performed

I ruled out:

• ChatGPT authentication
• Codex CLI connectivity
• proxy configuration
• Codex config.toml
• other enabled extensions
• corrupted extension installation
• corrupted VS Code Webview cache
• corrupted VS Code user profile

A clean/isolated VS Code process worked, and the same normal profile and
extension directory also worked when VS Code was started using code ..

Workaround

I created a user-level desktop entry and changed its Exec entries from:

Exec=/usr/share/code/code ...

to:

Exec=/usr/bin/code ...

After completely terminating all existing VS Code processes and launching
from the updated desktop entry, Codex loads normally.

Commands used:

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

This suggests that launching the Electron binary directly has a different
environment or initialization path from launching through the official
/usr/share/code/bin/code wrapper.

The immediate failure occurs in VS Code local Webview asset loading, not in
the Codex app-server or authentication layer.

Confirmed on an independent Fedora setup that routing the desktop entry through the VS Code CLI wrapper resolves this failure.

Environment (sanitized)

• Fedora Linux 44, GNOME/Wayland, x86_64
• VS Code 1.129.1
• openai.chatgpt@26.715.31925
• Local workspace (no Remote SSH)

Failure signature

When the application launcher used the raw Electron binary:

Exec=/usr/share/code/code %F

the Codex app-server started and completed initialization, but the webview did not finish bootstrapping. Developer Tools showed:

• local bundled JS/CSS requests failing with net::ERR_FAILED
• Unable to preload CSS
• repeated doReadFileStream -> readFileStream -> loadResource stacks
• listener growth from 175 to 263, 350, 438, 526, and 614

The failed assets were present and readable on disk. Static inspection of this extension build's webview entry showed a startup dependency preload list containing 676 assets, which may explain why this launch-path difference becomes visible as resource/listener pressure.

Only change made

I installed user-level desktop-entry overrides that route both normal launches and URL handling through the wrapper:

Exec=/usr/bin/code %F
Exec=/usr/bin/code --new-window %F
Exec=/usr/bin/code --open-url %U

I then refreshed the user desktop database, fully quit VS Code, and relaunched it from the application menu.

Codex now initializes normally, and the failure has not recurred during verification. I did not clear caches, reinstall or downgrade the extension, change authentication, change GPU settings, or modify the workspace.

This independently confirms that the workaround applies beyond Debian/Ubuntu and still applies to the newer extension/VS Code versions above. It also connects the launch-path issue here with the webview resource-failure signature in #32530 and the analogous investigation in posit-dev/positron#14889.