Repository navigation
OpenCode Desktop v1.17.14 can get stuck in an infinite startup crash loop with: Error: Notification server not found: http://[server-ip]:4096 #35686
Description
Description
Bug
OpenCode Desktop v1.17.14 can get stuck in an infinite startup crash loop with: Error: Notification server not found: http://[server-ip]:4096
The error appears shortly after app startup, and there is no way to clear it from the UI. Restart and Reload Webview do not fix it; the same error comes back on the next launch.
What Happened
I encountered this after a hard crash on macOS 27.0 beta. The entire macOS UI froze, so I had to hard reset the computer.
After rebooting, OpenCode Desktop was stuck in this state whenever I opened it. The IP address in the error is an OpenCode server on my local network, and I can connect to that server normally outside of this crash loop.
Expected Behavior
OpenCode Desktop should not crash during startup because notification state is missing for a server key.
If notification state cannot be found for the active server, the app should continue loading and treat notifications for that server as empty/unavailable.
Actual Behavior
https://i.imgur.com/PrzmNdu.png
The renderer crashes during app startup with:
Error: Notification server not found: http://[server-ip]:4096
at ensure (oc://renderer/assets/main-B1osgIPb.js:85602:24)
at selected (oc://renderer/assets/main-B1osgIPb.js:85634:28)
at Object.unseenCount (oc://renderer/assets/main-B1osgIPb.js:85648:37)
at oc://renderer/assets/main-B1osgIPb.js:109261:107
at Array.reduce (<anonymous>)
at Object.fn (oc://renderer/assets/main-B1osgIPb.js:109261:47)
at runComputation (oc://renderer/assets/main-B1osgIPb.js:487:22)
at updateComputation (oc://renderer/assets/main-B1osgIPb.js:470:3)
at Object.readSignal (oc://renderer/assets/main-B1osgIPb.js:403:67)
at Object.fn (oc://renderer/assets/main-B1osgIPb.js:109269:72)
at runComputation (oc://renderer/assets/main-B1osgIPb.js:487:22)
at updateComputation (oc://renderer/assets/main-B1osgIPb.js:470:3)
at createMemo (oc://renderer/assets/main-B1osgIPb.js:119:3)
at ProjectIcon (oc://renderer/assets/main-B1osgIPb.js:109269:18)
This leaves the app unusable.
Debugging Notes
The crash appears to come from a stale/missing server key reaching the notification context.
At render time, a project icon asks for unseen notification count:
ProjectIcon
-> notification.project.unseenCount(directory)
-> selected()
-> ensure(activeServer())
The relevant source path appears to be:
packages/app/src/pages/layout/sidebar-items.tsx
ProjectIcon renders unseen notification count
packages/app/src/context/notification.tsx
selected() calls ensure(activeServer())
ensure() looks up the active server key in global.servers.list()
The failing condition is:
active server key: http://[server-ip]:4096
current server list: sidecar only
So notification lookup tries to resolve:
http://[server-ip]:4096
but the active runtime server list does not contain a connection with that key. It only contains the desktop sidecar connection.
The current behavior is fatal:
const conn = global.servers.list().find((item) => ServerConnection.key(item) === key)
if (!conn) throw new Error(`Notification server not found: ${key}`)
Because this throw happens during a Solid reactive render path, the renderer crashes. On reload, the app restores the same persisted/default state, reaches the same render path, and crashes again. That creates the infinite loop.
Suspected State Mismatch
From debugging the local state, this looked like a mismatch between persisted/default server identity and the runtime server list.
The stale key came from the configured/default remote server:
defaultServerUrl = http://[server-ip]:4096
But on desktop startup, the available runtime server list contained the local sidecar connection rather than a direct connection keyed by that remote URL.
After the hard macOS reset, persisted state still referenced the remote server key in project/session state, but the server list no longer had a corresponding server entry. That made notification state lookup fail during initial rendering.
The likely shape was:
server.key / active notification key:
http://[server-ip]:4096
global.servers.list():
sidecar
persisted project/session state:
references http://[server-ip]:4096
Why This Is Fatal
The missing server only affects notification badge state, but the exception is thrown synchronously while rendering the app shell/sidebar. That means a cosmetic notification lookup can crash the whole desktop renderer.
Expected fallback behavior for this path would be something like:
ready: false
session notifications: []
project notifications: []
unseen counts: 0
markViewed: no-op
That would preserve debuggability while preventing the renderer from crashing.
Temporary fix
I was able to clear the error temporarily by deleting opencode.global.dat. However, the error returned after I opened the app and connected to the server again.
I was able to stop the crash loop by removing the saved defaultServerUrl value from the OpenCode Desktop settings/config, so the app no longer started with the stale remote server key.
Environment
- OpenCode Desktop: v1.17.14
- macOS: 27.0 beta
- Server: OpenCode server on local network at
http://[server-ip]:4096
Screenshot
https://i.imgur.com/PrzmNdu.png
Plugins
None
OpenCode version
v1.17.14
Steps to reproduce
-
Configure OpenCode Desktop v1.17.14 with
defaultServerUrlpointing to a remote/local-network OpenCode server, for examplehttp://[server-ip]:4096. -
Have persisted desktop state that references that server key in project/session state, but where the server list no longer contains a matching server entry.
-
Launch OpenCode Desktop.
-
The app attempts to render project/session notification badges during startup.
-
The renderer crashes with:
Error: Notification server not found: http://[server-ip]:4096
Screenshot and/or share link
https://i.imgur.com/PrzmNdu.png
Operating System
MacOS 27 Beta. Version 27.0.0: Mon Jun 15 22:59:49 PDT 2026; root:xnu-13432.0.5.501.1~2/RELEASE_ARM64_T6020 arm64
Terminal
N/A, this is the opencode desktop app
Activity
github-actions commentedon Jul 7, 2026
This issue might be a duplicate of existing issues. Please check:
Meepo268 commentedon Jul 9, 2026
我在win11上遇到了同样的问题,解决办法是指定 默认服务器。
Edison-A-N commentedon Jul 10, 2026
Reproduced on v1.17.18 (Linux server + remote Desktop client)
Same crash, same stack trace, different port and slightly newer version. Adding my data point to confirm this is not fixed in v1.17.14 → v1.17.18 (3 releases span).
Environment
opencode serve --port 10013 --hostname 0.0.0.0on Linux (x86_64)defaultServerUrl→http://<server-ip>:10013Stack trace (identical failure path)
Same
ProjectIcon→unseenCount→ensure()→ throw → SolidJS reactive crash.Observations from the server side
On the server,
opencode serveis healthy and listening:The server returns 401 on the root path (auth required), but the Desktop renderer treats the notification lookup failure as a fatal throw inside the Solid reactive render path, freezing the entire UI — not just the notification badge.
Impact
Expected behavior (same as original report)
A missing/stale notification server entry should degrade gracefully to
unseenCount = 0instead of throwing synchronously inside the render path. The notification subsystem should never be able to crash the app shell.Workaround that worked for me
Removing the persisted
defaultServerUrl/ clearingopencode.global.daton the Desktop side (same as the original report).Note
This reproduces without a hard OS crash on the Desktop side — simply connecting a remote Desktop client to a LAN
opencode serveinstance can trigger it when the persisted server key does not match the runtime server list. The bug is latent in the normal remote-server deploy, not only post-crash recovery.Edison-A-N commentedon Jul 10, 2026
Update: server auth removed, Desktop still crashes — confirms root cause is persisted state mismatch, not auth
After removing server-side authentication (verified
GET /and notification endpoint both return200), the Desktop renderer still crashes with the identical error. This confirms the root cause described in the original report: the crash is caused by a persisted state mismatch inopencode.global.dat, not by a server-side auth/connection failure.What is
opencode.global.datIt is the Desktop client's binary persisted global state file, stored locally on the Desktop machine (not on the server). It persists:
global.servers.list()defaultServerUrlWhy deleting it temporarily fixes the crash
The bug is a mismatch between persisted state and runtime server list:
On every Desktop launch → reads
opencode.global.dat→ restoresactiveServer = http://<server-ip>:10013/→ProjectIconrenders → callsunseenCount→ensure(activeServer)searchesglobal.servers.list()→ key not found →throw new Error("Notification server not found: ...")→ SolidJS reactive render path crashes → entire UI freezes.Deleting
opencode.global.dat= clear all persisted state → Desktop starts fresh → no stale server key → no throw → UI loads normally.But it recurs
As the original reporter noted, the fix is temporary: once you reconnect to the remote server from Desktop, the server key gets written back into
opencode.global.dat. On the next launch, if the runtime server list again does not contain that key, the crash returns. This creates a reproducible crash loop on every cold start for the remote-server deploy pattern.Confirmed diagnosis
This is not an edge case from an OS hard crash. It reproduces in a standard deploy:
opencode serve --port 10013 --hostname 0.0.0.0(Linux, healthy, returns 200)defaultServerUrl/ server key inopencode.global.datdoes not match the runtime server list on next startupThe fatal code path remains:
A missing notification server entry should degrade to
unseenCount = 0(no-op fallback), not throw synchronously inside the SolidJS reactive render path and freeze the entire application.Bilge commentedon Jul 16, 2026
I have no
defaultServerUrl, so I have no temporary workaround.opencode-agent commentedon Jul 20, 2026
Fixed by #37890.