[BUG] OpenCode Desktop NodeService hangs after sending a message, without useful logs #28332

Environment

• OS: Windows 11
• OpenCode Desktop version: 1.15.5
• Packaged Desktop app

This does not appear to be model-specific.

Summary

Sometimes after sending a message in OpenCode Desktop, the local server becomes unavailable/red in the UI.

The backend process does not crash. It remains alive and keeps listening on the local TCP port, but stops responding to requests.

This can happen in an existing session, and I have also seen similar behavior in a newly started/empty chat. I also observed that /compact may appear to finish, but the session hangs immediately after that.

Actual behavior

After the hang:

• Desktop shows the local server as unavailable/red.
• The OpenCode process is still running.
• The TCP port is still open.
• /global/health times out.
• No useful backend error is printed.
• Electron/Chromium verbose logs continue, but they do not show the stuck backend operation.

Example:

Test-NetConnection 127.0.0.1 -Port <port>
# TcpTestSucceeded : True

But:

Invoke-WebRequest http://127.0.0.1:<port>/global/health -TimeoutSec 3
# timeout

The process owning the port is:

OpenCode.exe --type=utility --utility-sub-type=node.mojom.NodeService

Expected behavior

OpenCode should either:

• complete the request;
• fail with a visible/logged error;
• or keep the backend responsive enough for health checks and recovery.

It should not leave the NodeService listening on the port but completely unresponsive.

Debugging attempts

I started Desktop from PowerShell with verbose logging:

cmd /c ".\\OpenCode.exe --enable-logging=stderr --v=1 2>\&1"

Startup logs show:

sidecar connection started
spawning sidecar
server ready

After reproducing the hang, there is no useful backend error.

I also tried enabling Node inspector:

$env:NODE\_OPTIONS="--inspect=127.0.0.1:9229 --enable-source-maps"

But the packaged app prints:

Most NODE\_OPTIONs are not supported in packaged apps.

So I could not attach a JS debugger to the packaged Desktop NodeService.

I also captured a Windows dump of the hung process. WinDbg classified it as a BusyHang in the NodeService process, with the blocking thread named node.CrUtilityMain.

CPU usage was not high, so this does not look like a CPU spin loop. It looks more like a blocked request handler, deadlock, or stuck async pipeline.

Possible related area

This may be related to one of these areas:

• session loading;
• session timeline rendering;
• session compaction;
• session summary generation;
• diff collection;
• large session payloads;
• NodeService request handling.

Request

Could OpenCode provide a better way to debug this class of Desktop hang?

For example:

• a supported way to enable Node inspector for the packaged Desktop NodeService;
• a diagnostic endpoint showing the current running request/session operation;
• timeout logging around session load, compaction, diff summary, and timeline rendering;
• logging of current session/message ids when NodeService becomes unresponsive;
• a way to dump JS stack traces from the packaged Desktop NodeService.

Currently, --log-level DEBUG, --print-logs, and Electron verbose logging do not reveal what operation is stuck.