What version of the Codex App are you using (From “About Codex” dialog)?
ChatGPT Desktop Linux package: 26.908.31748 Bundled app-server reported at startup: 0.154.0-alpha.6.1 The installed package and the current OpenAI stable Debian repository both advertise 26.908.31748. The app also selects/downloads Codex primary runtime 26.909.12148.
What subscription do you have?
Paid ChatGPT plan. Exact account tier omitted from the public report because it does not appear relevant to reproduction.
What platform is your computer?
- Debian GNU/Linux 13 (trixie) - x86_64 / amd64 - KDE Plasma desktop - Installed from OpenAI's official Linux Debian repository
What issue are you seeing?
The official ChatGPT Linux desktop app fails during startup and displays:
ChatGPT hit a snag
Something went wrong. Try again to continue.
The web version of ChatGPT works normally on the same machine/account/network.
The local bundled Codex app-server starts successfully, the initialization handshake succeeds, and the app-server reaches connected. The failure then occurs in the Electron/React renderer.
Key log sequence:
[AppServerConnection] Current reported app-server version:
currentVersion=0.154.0-alpha.6.1
[AppServerConnection] initialize_handshake_result
outcome=success transportKind=stdio
[AppServerConnection] Codex CLI initialized
[AppServerConnection] app_server_connection.state_changed
next=connected
Immediately afterward:
[electron-message-handler] Initial route prefetch failed; rendering will retry
errorMessage="n is not a function"
errorName=Error
route=primary
windowType=electron
The renderer also reports:
Matched leaf route at location "/" does not have an element or Component.
This means it will render an <Outlet /> with a null value by default
resulting in an "empty" page.
The fatal renderer error is then caught by the application error boundary:
Electron renderer console [error]
TypeError: n is not a function
[electron-message-handler] error boundary
errorMessage="n is not a function"
errorName=Error
name=AppRoutes
This corresponds to the visible “ChatGPT hit a snag” screen.
A KDE System Settings → Shortcuts window also sometimes opens during startup and shows two entries such as:
ChatGPT shortcut: electron-accelerator-6291776:
No active shortcuts
This appears incidental rather than causal, because the renderer failure is independently reproduced with clean app state.
What steps can reproduce the bug?
Normal launch
- Install the current stable ChatGPT Linux package from OpenAI's Debian repository.
- Launch
chatgpt.
- The window opens but then displays “ChatGPT hit a snag”.
- The renderer logs
TypeError: n is not a function with name=AppRoutes.
Reinstall does not help
sudo apt update
sudo apt-get install --reinstall chatgpt
pkill -fi chatgpt
chatgpt
The same startup-fatal screen occurs.
Clean Electron profile + clean Codex home also reproduces
pkill -fi chatgpt
rm -rf /tmp/chatgpt-clean-profile
rm -rf /tmp/codex-clean
mkdir -p /tmp/codex-clean
CODEX_HOME=/tmp/codex-clean \
chatgpt --user-data-dir=/tmp/chatgpt-clean-profile
The same failure occurs.
Disabling apps/plugins also reproduces
pkill -fi chatgpt
rm -rf /tmp/chatgpt-noplugins
rm -rf /tmp/codex-noplugins
mkdir -p /tmp/codex-noplugins
cat > /tmp/codex-noplugins/config.toml <<'EOF'
[features]
apps = false
plugins = false
EOF
CODEX_HOME=/tmp/codex-noplugins \
chatgpt --user-data-dir=/tmp/chatgpt-noplugins
Even with a fresh profile and both features disabled, startup still fails with:
Initial route prefetch failed; rendering will retry
errorMessage="n is not a function"
followed by:
TypeError: n is not a function
name=AppRoutes
The fatal renderer failure occurs before the later bundled-plugin reconciliation, so plugin installation does not appear to be the primary trigger.
Package verification
dpkg-query -W -f='${Version}\n' chatgpt
returns:
The OpenAI stable Debian repository also advertises:
and:
produces no output.
What is the expected behavior?
The Linux desktop application should render its normal home/sign-in interface after the app-server initializes successfully.
A frontend routing/rendering exception should not replace the application with the fatal “ChatGPT hit a snag” screen.
Additional information
Confirmed during troubleshooting:
- ChatGPT works normally in the browser.
- Reinstalling the official
.deb does not change the behavior.
dpkg -V chatgpt reports no modified/corrupt tracked package files.
- A completely fresh Electron user-data directory reproduces the failure.
- A completely fresh
CODEX_HOME reproduces the failure.
- Explicitly disabling both
apps and plugins still reproduces the same renderer exception.
- The bundled app-server itself initializes successfully and reaches
connected; the observed startup-fatal failure is in the renderer/UI path.
- The app currently selects Codex primary runtime
26.909.12148 while the stable desktop package remains 26.908.31748. This may be normal independent runtime rollout behavior; I am not asserting that the version difference is causal.
- During another clean-profile run, a later bundled-plugin reconciliation produced
plugin 'sites' was not found in marketplace 'openai-bundled', but the no-plugins reproduction shows the AppRoutes renderer failure occurs independently and earlier.
Possibly related but not exact duplicates:
run.log
What version of the Codex App are you using (From “About Codex” dialog)?
ChatGPT Desktop Linux package:
26.908.31748Bundled app-server reported at startup:0.154.0-alpha.6.1The installed package and the current OpenAI stable Debian repository both advertise26.908.31748. The app also selects/downloads Codex primary runtime26.909.12148.What subscription do you have?
Paid ChatGPT plan. Exact account tier omitted from the public report because it does not appear relevant to reproduction.
What platform is your computer?
What issue are you seeing?
The official ChatGPT Linux desktop app fails during startup and displays:
The web version of ChatGPT works normally on the same machine/account/network.
The local bundled Codex app-server starts successfully, the initialization handshake succeeds, and the app-server reaches
connected. The failure then occurs in the Electron/React renderer.Key log sequence:
Immediately afterward:
The renderer also reports:
The fatal renderer error is then caught by the application error boundary:
This corresponds to the visible “ChatGPT hit a snag” screen.
A KDE System Settings → Shortcuts window also sometimes opens during startup and shows two entries such as:
This appears incidental rather than causal, because the renderer failure is independently reproduced with clean app state.
What steps can reproduce the bug?
Normal launch
chatgpt.TypeError: n is not a functionwithname=AppRoutes.Reinstall does not help
The same startup-fatal screen occurs.
Clean Electron profile + clean Codex home also reproduces
The same failure occurs.
Disabling apps/plugins also reproduces
Even with a fresh profile and both features disabled, startup still fails with:
followed by:
The fatal renderer failure occurs before the later bundled-plugin reconciliation, so plugin installation does not appear to be the primary trigger.
Package verification
dpkg-query -W -f='${Version}\n' chatgptreturns:
The OpenAI stable Debian repository also advertises:
and:
produces no output.
What is the expected behavior?
The Linux desktop application should render its normal home/sign-in interface after the app-server initializes successfully.
A frontend routing/rendering exception should not replace the application with the fatal “ChatGPT hit a snag” screen.
Additional information
Confirmed during troubleshooting:
.debdoes not change the behavior.dpkg -V chatgptreports no modified/corrupt tracked package files.CODEX_HOMEreproduces the failure.appsandpluginsstill reproduces the same renderer exception.connected; the observed startup-fatal failure is in the renderer/UI path.26.909.12148while the stable desktop package remains26.908.31748. This may be normal independent runtime rollout behavior; I am not asserting that the version difference is causal.plugin 'sites' was not found in marketplace 'openai-bundled', but the no-plugins reproduction shows theAppRoutesrenderer failure occurs independently and earlier.Possibly related but not exact duplicates:
run.log