[BUG] Windows: Sidecar handle leak causes desktop freeze + persistent server polling errors #23734

Bug Description

On Windows 11, the OpenCode Desktop sidecar (opencode-cli) exhibits two critical issues:

1. Windows Handle (HND) leak — Handles explode from ~385 to 7,000–12,000+ in ~90 seconds, accompanied by connection spikes (32→287+), causing the sidecar to become unresponsive and the desktop UI to freeze.
2. Persistent service=server error= failed — A recurring server error fires every 6–31 seconds in every sidecar instance from the first second of startup, regardless of active sessions.

Environment

• OS: Windows 11 Home (build 26200)
• Desktop app: v1.14.20 (upgraded from earlier version, issue persists)
• Sidecar: opencode-cli (bundled with desktop app)
• MCP servers configured: playwright, chrome-devtools, context7, grep_app, web-reader, zread, web-search-prime
• Projects: 8 registered projects with 30 sessions in SQLite DB

Issue 1: Windows Handle Leak → Desktop Freeze

Reproduction

The handle leak appears unpredictably during normal usage (sending messages, switching sessions). It does not occur during idle benchmark runs (HND stable at 382–384 for 50+ minutes with no interaction).

Evidence: Process Monitor Data

A custom monitoring script captured the leak in real-time (sampled every 30s):

Before leak (normal state):

[19:08:39] PID=10228 PORT=1921 MEM=753MB CPU=34.2s THR=39 HND=355 CONN=41  health=401

Leak triggered (2 user messages sent):

[19:09:10] PID=10228 PORT=1921 MEM=882MB CPU=42s   THR=44 HND=1356 CONN=130 health=ERR
[19:09:48] PID=10228 PORT=1921 MEM=964MB CPU=68.3s THR=44 HND=4520 CONN=131 health=ERR
[19:10:26] PID=10228 PORT=1921 MEM=978MB CPU=95.5s THR=43 HND=4629 CONN=131 health=ERR

In another crash (port 9718), HND reached 12,684 in 90 seconds, and in a third crash (port 3775), HND reached 7,502.

Pattern: HND 355→4,629 in 107 seconds. Connection count 41→131. Health endpoint returns ERR (unresponsive). Frontend shows Error: error sending request for url (http://127.0.0.1:PORT/session/...).

Key Observation

The leak is triggered by active message processing, not by idle polling. A 50-minute benchmark run with no messages showed HND stable at 382–384 with zero leaks.

Issue 2: Persistent service=server error= failed

Description

Every sidecar instance logs service=server error= failed at regular intervals from the moment it starts. This has been present across all sidecar instances observed (7+ sessions), both before and after the v1.14.20 upgrade.

Evidence: Log Excerpts

First seconds after sidecar startup:

2026-04-21T15:13:30.989Z  INFO  Loading done, completing initialisation
2026-04-21T15:13:36.743Z  INFO  ERROR service=server error= failed
2026-04-21T15:13:40.252Z  INFO  ERROR service=server error=Session not found failed
2026-04-21T15:13:40.708Z  INFO  ERROR service=server error=NotFoundError failed

Pre-upgrade frequency: ~31 seconds between errors (regular)
Post-upgrade frequency: ~6 seconds between errors (irregular, 3–13s)

Post-upgrade error count: 238 errors in 26 minutes (~9 errors/minute)

Additional Error: MCP prompts/list Not Found

All MCP servers consistently report MCP error -32601: Method not found for prompts/list. This fires at every MCP reconnection:

ERROR service=mcp clientName=playwright error=MCP error -32601: Method not found failed to get prompts
ERROR service=mcp clientName=chrome-devtools error=MCP error -32601: Method not found failed to get prompts
ERROR service=mcp clientName=context7 error=MCP error -32601: Method not found failed to get prompts
ERROR service=mcp clientName=grep_app error=MCP error -32601: Method not found failed to get prompts
ERROR service=mcp clientName=web-reader error=MCP error -32601: Method not found: prompts/list failed to get prompts
ERROR service=mcp clientName=zread error=MCP error -32601: Method not found: prompts/list failed to get prompts
ERROR service=mcp clientName=web-search-prime error=MCP error -32601: Method not found: prompts/list failed to get prompts

Issue 3 (NEW in v1.14.20): Git Snapshot Lock Contention

After upgrading to v1.14.20, a new error pattern appeared — git index.lock contention in the snapshot directory:

WARN  service=snapshot exitCode=128 stderr=fatal: Unable to create 'C:\Users\17865\.local\share\opencode\snapshot\<hash>\index.lock': File exists.
Another git process seems to be running in this repository...
remove the file manually to continue.
 failed to add snapshot files

65 instances of this error in 16 minutes. This error was not present before the v1.14.20 upgrade.

Post-Upgrade Stability

After upgrading to v1.14.20, the handle leak has not reproduced in 25+ minutes of monitoring:

[20:35:56] PID=60364 PORT=2739 MEM=930MB CPU=56.1s THR=34 HND=430 CONN=82 health=401
[20:42:49] PID=60364 PORT=2739 MEM=885MB CPU=66.2s THR=35 HND=425 CONN=81 health=401

HND stable at 425–432 for 20+ minutes. However, the service=server error= failed persists, and the new snapshot lock contention appeared.

Database State

• Sessions: 30 total, all marked active (time_archived IS NULL)
• Projects: 8 registered, all directories exist and accessible
• Database size: 19MB + 7MB WAL
• Snapshot repos: 3 directories under ~/.local/share/opencode/snapshot/

Suggested Investigation Areas

1. Handle leak: Check if the sidecar creates sockets/threads/timers during message processing that are never closed on Windows. The rapid HND growth (355→4,629 in 107s) suggests a resource creation loop without corresponding cleanup.
2. Server polling error: The service=server error= failed at startup suggests the server is trying to process or poll for sessions before fully initializing. The Session not found / NotFoundError variants hint at stale session references.
3. MCP prompts/list: The sidecar queries prompts/list on all MCP servers at startup and reconnection, but this method is optional in the MCP spec. Consider gracefully handling -32601 instead of logging errors.
4. Snapshot lock contention: The snapshot git operations appear to run concurrently without lock coordination on Windows, where file locking behavior differs from Unix.