Skip to content

桌面端打开报错，kill端口和set新端口都无法解决 #54071

New issue
New issue
Open
Open
桌面端打开报错，kill端口和set新端口都无法解决#54071
Assignees
Brendonovich

Description

@4x8hwz9rwk-rgb
4x8hwz9rwk-rgb
opened on Oct 9, 2026

Description

Error: Desktop IPC handler failed
at Wt (oc://renderer/assets/main-LpOAv9Ye.js:2:30739)
at Ut (oc://renderer/assets/main-LpOAv9Ye.js:2:30407)
at MessagePort. (oc://renderer/assets/main-LpOAv9Ye.js:2:29127)

────────────────────────────────────────
原因：
{
"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-gn3byahv.js:2:8762) {\n [cause]: ServeError: \n at A (B:/~BUN/root/chunk-gfcr6bw6.js:52:46739)\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-gfcr6bw6.js:52:46777)\n }\n}"
}
}

Plugins

No response

OpenCode version

2.0.26

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response

Activity

  1. github-actions
    assigned
    Brendonovich
    on Oct 9, 2026

  2. opencode-agent commented on Oct 9, 2026

    @opencode-agent
    opencode-agentBot
    on Oct 9, 2026 – with OpenCode Agent
    Contributor

    感谢反馈！从报错路径看这是 Windows 上的 OpenCode Desktop v2（2.0.26）。为了判断问题原因，请补充以下信息：

    1. 操作系统及版本（例如 Windows 11 23H2）。
    2. 你具体是怎么设置新端口的？请贴出完整命令，并说明是在哪里运行的（单独安装的 opencode CLI 还是其他方式），以及 opencode service get port 的输出。
    3. 设置新端口后重新打开桌面端，报错里显示的端口还是 49374 吗？如果不是，请贴出新的完整报错。
    4. 在 PowerShell 中运行以下命令并贴出结果，用来确认 49374 是否落在 Windows 的保留端口范围内（这种情况下没有进程占用端口，所以 kill 端口不起作用）： 
      netsh interface ipv4 show excludedportrange protocol=tcp
netstat -ano | Select-String "49374"

    可以直接在这里回复，也可以编辑 issue；如果选择编辑，请再留一条评论告诉我们已更新，这样我们才知道你改完了。

    以下是可能相关的 issue，按可能性从高到低排列，你可以看看是否已经涵盖了你的问题：

    另外 #53888 是一个仍在审核中的 PR，目标是让桌面端在端口冲突时可以恢复。

    English: Thanks for the report! Please share your Windows version, the exact command you used to set the new port and where you ran it, the output of opencode service get port, whether the error still shows port 49374 after setting a new port, and the output of netsh interface ipv4 show excludedportrange protocol=tcp. You can reply here or edit the issue (if you edit it, please also leave a comment so we know you're done). Possibly related, ordered by likelihood: #53351, #52234, #50672. #53888 is an open PR that aims to let the desktop app recover from port conflicts.

  3. opencode-agent
    added
    triaging
    on Oct 9, 2026

  4. 4x8hwz9rwk-rgb commented on Oct 9, 2026

    @4x8hwz9rwk-rgb
    4x8hwz9rwk-rgb
    on Oct 9, 2026
    Author
    1. 操作系统及版本

    Windows 11 23H2（OS 内部版本 22631.【请替换为你的实际版本号，可在 CMD 运行 winver 查看】）

    1. 设置新端口的方式

    使用独立安装的 OpenCode CLI，在普通 CMD（非管理员）中执行：

    bash
    opencode service set port 54321
    该命令执行后无任何输出，直接返回提示符，没有报错。

    1. 设置新端口后的报错

    设置成 54321 后重新打开桌面端，报错里显示的端口确实变成了 54321，不再是 49374：

    text
    Error: Managed service port 54321 on 127.0.0.1 is already in use by another process.
    4. 端口是否落在 Windows 保留范围内

    运行 netsh interface ipv4 show excludedportrange protocol=tcp 的输出：

    text
    协议 tcp 端口排除范围

    开始端口 结束端口

      5357        5357
 50000       50059     *
      • 管理的端口排除。
        结论：49374 和 54321 都不在 Windows 的排除端口范围内，所以这个问题应该不是由系统保留端口引起的。netsh 的结果也印证了这一点——排除范围只有 5357 和 50000–50059。

    结合之前手动 taskkill 掉占用 54321 的进程（PID 4184）后、重新打开桌面端依然报同样的“already in use”，我怀疑是 OpenCode 自身的服务进程管理或端口探测逻辑存在残留/误判，而不是端口真的被系统或其他程序占用。

  5. opencode-agent
    removed
    triaging
    on Oct 9, 2026

  6. opencode-agent commented on Oct 9, 2026

    @opencode-agent
    opencode-agentBot
    on Oct 9, 2026 – with OpenCode Agent
    Contributor

    Thanks for the details, they ruled out the Windows reserved-port explanation (#53351).

    I tried this on Linux with 2.0.26 and couldn't trigger it the way you describe:

    • If an OpenCode service is already running on the configured port, a second managed start, which is how the desktop app starts its service, recognises it and exits normally.
    • After the service is killed, the port is free right away and a new service starts on it.
    • The "already in use by another process" error only appears when a program other than OpenCode holds the port.

    In your case the port still counts as in use after you killed the owning process, which points to something Windows-specific (or to the desktop app and the separately installed CLI clashing over the same port). That needs a maintainer with a Windows machine to look into.

    If you can, these would help:

    • Right after the error, run netstat -ano | findstr 54321, then tasklist /FI "PID eq <pid>" with the PID it shows. Do the same again after taskkill. This tells us which program is holding the port and whether a new one takes it over.
    • Tell us whether a terminal OpenCode session (opencode) or a opencode serve process was running at the time.

    Related: #52234 (the service port has no fallback when it's unavailable). #53888 is an open pull request that aims to let the desktop app recover from port conflicts.

  7. 4x8hwz9rwk-rgb commented on Oct 9, 2026

    @4x8hwz9rwk-rgb
    4x8hwz9rwk-rgb
    on Oct 9, 2026
    Author

    @opencode-agent Thanks. I reproduced it as requested, and the result is clear: the port is occupied, but by OpenCode's own CLI process.

    Right after the error:

    netstat -ano | findstr 54321
    TCP 127.0.0.1:54321 0.0.0.0:0 LISTENING 20456
    TCP 127.0.0.1:62882 127.0.0.1:54321 SYN_SENT 15740
    TCP 127.0.0.1:62883 127.0.0.1:54321 SYN_SENT 10516

    tasklist /FI "PID eq 20456"
    opencode-cli.exe 20456 Console 1 154,008 K

    tasklist /FI "PID eq 15740"
    OpenCode.exe 15740 Console 1 156,068 K

    Interpretation:

    • 20456 = opencode-cli.exe: the managed service actually started and is listening on 54321.
    • 15740 = OpenCode.exe: the Desktop app, trying to connect to 54321, stuck in SYN_SENT.
    • 10516: already exited.

    So:

    1. The port is NOT held by an external program — it is held by OpenCode's own CLI service.
    2. Desktop did not recognize that an OpenCode service was already running on that port, treated it as external, and failed with "already in use".
    3. Desktop's connection to the port is stuck in SYN_SENT, meaning it could not connect even though the service is listening.

    This is the opposite of the Linux behavior you described ("recognises it and exits normally") — on Windows, Desktop does not recognize its own service.

    Additional info you asked for:

    • No terminal opencode (TUI) session was running at the time.
    • No separate opencode serve process was running at the time.
    • CLI is installed via npm globally: C:\nvm4w\nodejs\opencode
    • opencode --version → opencode v2.0.26
    • Desktop is installed separately.

    I suspect the mechanism Desktop uses on Windows to detect an existing OpenCode service (PID file, lock file, or health check) is not working, or the CLI version/path Desktop launches does not match what it expects.

    Happy to provide Desktop startup logs or compare the bundled CLI vs. the npm-installed CLI if that helps.

    One more critical observation — this is not limited to the Desktop IPC layer.

    After the Desktop failure, I also cannot start opencode from the terminal anymore (it worked before). Running opencode in CMD now gives the exact same error:

    C:\Users\HP>opencode
    Starting background server...
    Error: Server process exited with code 1
    Error: Managed service port 54321 on 127.0.0.1 is already in use by another process.
    ...
    at map (unknown:1:11)
    at reap (B:/~BUN/root/chunk-4nv6qems.js:2:1159)
    at (B:/~BUN/root/chunk-4nv6qems.js:3:6711)
    at service.ensure (B:/~BUN/root/chunk-kf7vq7zm.js:3:690)
    at service.ensure (definition) (B:/~BUN/root/chunk-4nv6qems.js:3:5523)
    at cli.server-connection.resolve (B:/~BUN/root/chunk-vb7xa2as.js:96:6563)
    at cli.server-connection.resolve (definition) (B:/~BUN/root/chunk-kf7vq7zm.js:2:402)

    Important: the stack trace shows reap running inside service.ensure. This means the CLI tries to clean up stale service processes before starting a new one, but the reap logic fails to clean up the opencode-cli.exe that is holding port 54321. As a result, any new service start (Desktop or CLI) hits the same occupied port and fails.

    This points to a stuck/ghost managed-service process on Windows that reap cannot detect or terminate. Manual opencode serve --port 54321 works because it bypasses the service.ensure / reap path entirely.

  8. imyu37 commented on Oct 13, 2026

    @imyu37
    imyu37
    on Oct 13, 2026

    TL;DR (EN): Same failure family on Windows / opencode 2.0.27 — the managed service fails its boot (SQLiteError: disk I/O error) but stays alive holding the port, answering 500/503; every later start attempt therefore ends with Background service failed to start, and killing the port / changing ports cannot help. DB integrity, disk and volume health were all verified OK; a WAL-checkpoint + VACUUM repair restored a healthy service.

    补充一条同症状但因果链更完整的现场记录，希望能补上本 issue 缺的根因证据。环境：Windows 11 + opencode 2.0.27（桌面端 @opencodedesktop 与 CLI 同版本，opencode --version → opencode v2.0.27）。库 ~/.local/share/opencode/opencode.db 约 2.1 GB，WAL 约 125 MB。

    1. 现象（与本 issue 一致）

    桌面端：Error: Desktop IPC handler failed → cause: {"message":"Background service failed to start"}
    CLI：Error: Background service failed to start

    2. 关键证据：占着端口的是 opencode 自己的降级服务

    服务侧日志给出了真正的失败点（注意这一行不是 port in use，而是引导阶段写库失败）：

    timestamp=2026-10-13T01:43:17Z level=ERROR run=110b870d
  message="background service boot failed" cause="Cause([Die(SQLiteError: disk I/O error)])" role=server

    该 run 在引导失败之后仍然存活并继续监听，对所有请求返回 5xx（持续到人工终止该进程）：

    接口 降级时 修复后（健康）
    /api/info 500 200（opencode api GET /api/info 返回 version/pid JSON）
    /api/event、/api/session/*、/api/config、/api/vcs、/api/fs/find 503 正常
    无认证访问 /api/info 500 401（认证层正常工作）

    netstat -ano 显示该端口 LISTENING 的 PID 与 ~/.local/state/opencode/service.json 中登记的服务 PID 完全一致，进程名 opencode-cli —— 与本 issue 最后一条评论的结论相同：占用端口的是 OpenCode 自家的 CLI 进程，所以 kill 端口、service set port 换端口都不可能生效（换端口后只会看到新端口同样被自家降级服务占住）。

    顺带一个可用的判别口诀：端口在监听、但 /api/info 既不是 401（认证）也不是 200（已认证）→ 基本就是"引导失败的降级服务"，应终止进程后重启服务，而不是反复点重试。

    3. 已排除：不是库损坏，也不是磁盘/硬件故障

    检查 结果
    PRAGMA quick_check（只读，读全部 539,450 页 / 2.06 GB） ok，13.4 s 读完，期间无 I/O 错误
    系统日志 Microsoft-Windows-Ntfs C/D/E 卷"运行状况良好"，近 3 天无磁盘/坏道错误事件
    剩余空间 C: 59.7 GB / D: 314 GB（非空间不足）
    库内状态 journal_mode=wal、freelist_count=277658（约 1.06 GB 是库内空闲页）、opencode.db-wal 125.3 MB
    PRAGMA wal_checkpoint(TRUNCATE) 返回 **`0

    也就是说：读路径完好、结构与硬件完好，失败发生在启动期的写入路径，而服务在写失败后既没有重试、也没有退出。

    4. 有效的处置（可复现，供其他受害者参考）

    备份 opencode.db / -wal / -shm
→ 终止降级服务进程（释放端口）
→ PRAGMA wal_checkpoint(TRUNCATE) + VACUUM   # 2107 MB → 1017 MB，freelist 277658 → 0
→ opencode service start

    结果：连续两次启动（含 service restart）均无 boot failed；opencode api GET /api/info 正常；经后台服务（非 --standalone）的会话可正常写库；此后 boot failed 未再出现（持续观察中）。

    5. 期望的修复方向

    1. 引导失败必须释放端口：失败后应退出（或进入可被 service start 接管的状态），而不是保留监听端口以 5xx 应答——否则用户按报错提示 kill 端口、换端口全都无效。
    2. 启动期健康检查窗口/超时不宜过短（关联 desktop(win): background service SIGKILLed mid-turn when snapshot capture blocks /api/info for >6s -> ~60s restart loop, aborted turns #51216 / PR fix(desktop): prevent background service SIGKILL loops and tune SQLite WAL concurrency #53387 中提到的 supervisor requestTimeout: 2000、连续 3 次超时即驱逐）。
    3. 启动期写入失败应可重试（关联 PR fix(core): recover sessions and jobs from transient storage failures #53704「transient storage failures」的恢复思路）。

    6. 关联条目

    7. 一点未经证实的线索

    本机装有企业级 DLP / 文件过滤驱动（透明加密类），因此"启动期瞬时写失败"被怀疑与文件系统 I/O 过滤有关；但尚未证实，仅作为线索提供，不作为结论。

    如果你需要更进一步的信息（完整 opencode service status 输出、脱敏后的 run/role 日志片段、或按官方 troubleshooting 页要求的最小复现步骤），我可以补充。

  9. neriousy commented on Oct 19, 2026

    @neriousy
    neriousy
    on Oct 19, 2026
    Member

    Thanks for the netstat output. A port that is LISTENING under opencode-cli.exe while other connections to it stay in SYN_SENT suggests the existing service is alive but not answering, so each new launch can't recognize it and starts another one. To narrow down why it stops answering:

    1. Does this still happen on the latest Desktop (2.0.32)?
    2. How big is %USERPROFILE%\.local\share\opencode\opencode.db, and is it on an SSD or HDD?
    3. Do you use antivirus other than Windows Defender, a VPN, or a proxy tool (Clash, v2ray, etc.)? If you have HTTP_PROXY/HTTPS_PROXY/NO_PROXY set, please share them (remove credentials).
    4. Which plugins and MCP servers are in your config?
    5. Do you have WSL running, and have you ever started OpenCode as Administrator?
    6. When does it happen: after an update, after sleep/reboot, or after closing a previous session?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions