VS Code Codex panel does not start on Linux Mint unless VS Code is launched with --verbose

Reproduce on Linux Mint by launching VS Code with code and code --verbose, then compare the Codex extension, app-server, and renderer logs around initialization and route mounting. Focus on the chat session provider and renderer route-mounting behavior described in the report. Done means the panel reaches the mounted state during a normal code launch without requiring --verbose.

What version of Codex is running?

VS Code extension: openai.chatgpt-26.715.61943-linux-x64
Bundled Codex SDK shown by VS Code logs: codex 0.142.0

VS Code:

1.129.1
8a7abeba6e03ea3af87bfbce9a1b7e48fed567b8
x64

Which model were you using?

gpt-5.6-sol

~/.codex/config.toml contains:

model = "gpt-5.6-sol"
model_reasoning_effort = "low"

What platform is your computer?

Reproduced on two Linux Mint PCs.

Primary machine details:

Linux Mint 22.3 zena
Kernel: 6.8.0-136-generic
Architecture: x86_64
CPU: Intel i7-7700K
RAM: 62 GiB
GPU: AMD Radeon RX 470/480/570/580 family

Also reproduced previously on the same machine with kernel 6.14.0-37-generic.

Not reproduced on Windows. Not reproduced on macOS.

VS Code has had hardware acceleration disabled throughout via ~/.vscode/argv.json:

"disable-hardware-acceleration": true

What steps can reproduce the bug?

1. Start VS Code normally with code on Linux Mint.
2. Open the Codex panel/window.
3. The Codex window/panel refuses to start.
4. Close VS Code.
5. Start VS Code with code --verbose.
6. Open the Codex panel/window again.

What is the expected behavior?

The Codex panel should start normally whether VS Code is launched with code or code --verbose.

What do you see instead?

On normal code launch, the Codex extension activates and the app-server initializes, but the renderer/UI never reaches the app mounted state.

Normal launch Codex output has:

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

Then it stops there.

The normal launch renderer log also has:

Attempted to report in-progress status for unknown chat session type 'openai-codex'

When launched with code --verbose, the same extension/version works immediately and reaches:

[startup][renderer] app routes mounted after 2085ms

So --verbose appears to change timing/order enough for the Codex UI to mount.

Additional information

Recent VS Code coredumps on the Linux Mint machine include SIGBUS, SIGILL, and SIGTRAP for /usr/share/code/code, including compositor-related invalid opcode evidence, but the Codex-specific behavior is notable because code --verbose reliably makes the Codex window start.

Recent coredump summary:

Wed 2026-07-22 12:19:53 EEST SIGBUS  /usr/share/code/code
Wed 2026-07-22 12:22:44 EEST SIGILL  /usr/share/code/code
Wed 2026-07-22 12:24:02 EEST SIGTRAP /usr/share/code/code

The 403 /settings/user messages appear only after the UI successfully mounts in the verbose launch, so they do not appear to be the primary startup blocker.

This looks like a Linux/VS Code extension startup race around the Codex chat session provider or renderer route mounting. The reproducible workaround is launching VS Code as:

code --verbose