Repository navigation
Description
Description
On Windows, OpenCode Desktop 2.0.23 can fail to start its managed local service when the default service port 49374 falls inside a Windows TCP excluded port range.
On the affected system, port 49374 was not owned by any process, but Windows had excluded the range 49292–49391, which contains 49374. OpenCode nevertheless reported:
Managed service port 49374 on 127.0.0.1 is already in use by another process.
Configure another port with `opencode service set port <port>` and start the service again.
The managed-service path also retries the same unusable port instead of automatically selecting another available port.
Steps to reproduce
- Check the Windows excluded TCP ranges:
netsh interface ipv4 show excludedportrange protocol=tcp-
On the affected system,
49292–49391was excluded, so49374was inside the excluded range. -
Confirm that no process is listening on
49374:
netstat -ano | Select-String "49374"
Get-NetTCPConnection -LocalPort 49374Both returned no listener/owning process.
-
Start OpenCode Desktop 2.0.23. The managed service fails to start.
-
Reproduce directly with:
opencode serve --port 49374This fails even though no process owns the port.
- As a control, use another available port:
opencode serve --port 49400The service successfully binds to 127.0.0.1:49400.
Expected behavior
If the configured/default managed-service port cannot be bound, OpenCode should automatically recover by selecting another usable port, or report that the port is unavailable/reserved rather than claiming that another process owns it.
The service should not repeatedly retry the same unusable port.
Actual behavior
The managed service attempts to bind 49374, fails, and reports that the port is already in use even though no process owns it.
The user must manually configure another port to recover.
Technical details
The default OpenCode service port is 49374 (0xc0de).
In managed-service mode, the explicitly resolved port bypasses the existing available-port scan/fallback path. The retry logic retries the same port instead of selecting another usable port.
The bind failure is also surfaced through the existing EADDRINUSE-based "already in use" classification, resulting in a misleading user-facing error when the port is actually unavailable for binding.
Scope
This appears to be a Windows-specific manifestation of the managed-service bind failure. The issue is in the CLI/service layer used by Desktop; Desktop launches the bundled CLI using the managed-service path and does not independently select the service port.
Related to existing OpenCode/Bun issues involving listen/bind failures being surfaced as EADDRINUSE, but this report specifically concerns the default managed-service port 49374 falling inside a Windows excluded TCP port range and the lack of automatic fallback for the managed-service path.
Plugins
None
OpenCode version
2.0.23
Steps to reproduce
-
On Windows, check the excluded TCP port ranges:
netsh interface ipv4 show excludedportrange protocol=tcp
On the affected system,49292–49391was excluded, which contains the default OpenCode service port49374. -
Confirm that no process owns port 49374:
netstat -ano | Select-String "49374"
Get-NetTCPConnection -LocalPort 49374
Both return no listener. -
Start OpenCode Desktop 2.0.23. The managed service attempts to bind
127.0.0.1:49374and fails with:
Managed service port 49374 on 127.0.0.1 is already in use by another process. -
Reproduce directly with the bundled/CLI service:
opencode serve --port 49374
This fails even though no process is listening on the port. -
As a control, start the service on another available port such as
49400; it binds successfully and responds to/api/health.
Screenshot and/or share link
Error: Desktop IPC handler failed
at Wt (oc://renderer/assets/main-BEWlKRO-.js:2:30738)
at Ut (oc://renderer/assets/main-BEWlKRO-.js:2:30406)
at MessagePort. (oc://renderer/assets/main-BEWlKRO-.js:2:29123)
at MessagePort.i (oc://renderer/assets/esm-B7tn089r.js:15:6665)
────────────────────────────────────────
Caused by:
{
"name": "UnknownError",
"message": "An error occurred in Effect.tryPromise",
"cause": {
"name": "Error",
"message": "Server process exited with code 1\nError: Managed service port 49374 on 127.0.0.1 is already in use by another process. Configure another port with opencode service set port <port> and start the service again.\n at (B:/~BUN/root/chunk-b3kxkarp.js:2:7950) {\n [cause]: ServeError: \n at G (B:/~BUN/root/chunk-k64283rx.js:54:51704)\n at applyHandlers (node:events:64:20)\n at emitError (node:events:44:27)\n at emitListenErrorNextTick (node:_http_server:134:12)\n at processTicksAndRejections (unknown:7:39) {\n [cause]: Error: Failed to start server. Is port 49374 in use?\n at serve (unknown)\n at (node:_http_server:359:39)\n at (node:_http_server:332:33)\n at (B:/~BUN/root/chunk-k64283rx.js:54:51742)\n }\n}"
}
}
Operating System
Windows 11
Terminal
Windows Terminal (PowerShell)
Activity
github-actions commentedon Oct 5, 2026
This issue might be a duplicate of an existing issue. Please check:
HarshithReddyDev commentedon Oct 5, 2026
This appears to be a duplicate of #52234, which covers the same underlying managed-service bug: the default port 49374 has no fallback when unavailable, including WSL2/Hyper-V reserved ranges. My report provides a concrete Windows 11 reproduction where 49374 falls inside a Windows excluded TCP range while no process owns the port.
I have a tested fix in https://github.com/HarshithReddyDev/opencode/tree/fix/windows-excluded-service-port that adds fallback for the unbindable managed-service port.