VS Code Codex panel does not start on Linux Mint unless VS Code is launched with --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?
- Start VS Code normally with
codeon Linux Mint. - Open the Codex panel/window.
- The Codex window/panel refuses to start.
- Close VS Code.
- Start VS Code with
code --verbose. - 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
1 Comment
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action