desktop(win): background service SIGKILLed mid-turn when snapshot capture blocks /api/info for >6s -> ~60s restart loop, aborted turns #51216

Description

On Windows, the Desktop app kills its own background service while the service is
legitimately busy, which aborts the running turn and puts the app into a restart loop.

When a session's checkpoint work keeps the CLI's HTTP server busy for more than ~6 s,
the Desktop main process declares the background service "unresponsive", stops it
(SIGTERM -> SIGKILL) and spawns a new one. Every in-flight request is aborted
(HTTP 499), the running turn is interrupted, the app resumes it, the same work runs
again, and the cycle repeats roughly every 60 seconds.

User-visible result: the session is unusable. The activity list fills up with
"restart continuation" entries, background subagents end up "failed", and the app
never finishes a turn. In one day the CLI was started 111 times (vs. 3-6 starts/day
before the same app version), with 150 InterruptErrors.

The trigger in my case was the snapshot/checkpoint path:

timestamp=... level=INFO message=session.revert.stage sessionID=<session> messageID=<message> files=undefined http.span=862
timestamp=... cause="InterruptError: All fibers interrupted without error
    at Git.index.refresh (chunk-g2m6xm1v.js:24:2279)
    at Git.tree.capture (chunk-xm1wvpce.js:121:2381)
    at Snapshot.capture (chunk-xm1wvpce.js:121:4527)
    at SessionRevert.stage (chunk-xm1wvpce.js:137:1835)
    at Session.revert.stage (chunk-t9es9kf6.js:442:10196)"
    http.span=46646 role=server http.method=POST http.url=/api/session/<session>/revert/stage http.status=499

So POST /api/session/<id>/revert/stage ran for 46.6 s, blocked the CLI process, and
was then aborted by the app (499 = client went away, i.e. the service was killed).

While that capture was running I could verify the consequences directly:

• netstat/raw TCP connect to the registered service URL succeeded (the port was
  listening), but GET /api/info never answered — repeated 8 s timeouts.
• After the automatic replacement, the same endpoint answered
  200 {"version":"2.0.16","pid":<pid>,"urls":["http://127.0.0.1:<port>"],...} in ~5 ms.
• Same request again after reducing the work: 46.6 s -> 1.22 s (HTTP 200).

The Desktop main log shows the loop (trimmed, repeated every ~59 s for hours):

[17:26:18.018] [info]  (main)    starting v2 background service
[17:26:24.103] [info]  (main)    v2 CLI background service starting { reason: 'missing' }
[17:26:24.609] [info]  (main)    v2 CLI background service ready { url: 'http://127.0.0.1:<port>', ... }

Relevant behaviour in the packaged app (resources/app.asar -> out/main/service-*.js):

{ pollInterval: 25, requestTimeout: 2e3, spawnDelay: 5e3, maxSpawnDelay: 3e4,
  promiseTimeout: 12e4, stopPollInterval: 50, stopPollAttempts: 100 }

• the health probe is GET /api/info with a 2 s timeout;
• after 3 consecutive timeouts the service is declared unresponsive and
  replaced (SIGTERM, then SIGKILL, service.json deleted);
• the next ensure() then reports reason: 'missing' and spawns a new CLI;
• /api/info returning 503 is only ever treated as state: 'waiting'.

In other words: a backend that is busy doing real work for >6 s is treated as dead,
and the kill takes the running session down with it.

Expected Behavior

• A busy backend should not be considered dead after ~6 s. The health budget should
  be much larger and/or adaptive, and a service that is responding on its socket
  should not be SIGKILLed while a request is in flight.
• Killing/replacing the service should not silently abort running turns; the
  session state should survive a service replacement.
• Snapshot.capture should not block the HTTP server (see core: session never drains when Snapshot.capture() stalls on huge untracked tree — git add hangs, execution claim never released #48657 for the capture
  stall itself). At minimum, health/liveness endpoints should not be blocked by
  filesystem/git work.

Steps to reproduce

1. On Windows, use a git project whose untracked, non-ignored tree is large
   (in my case: a repo created by another tool with a single empty commit, no
   .gitignore, 76,921 untracked/non-ignored files, ~11.8 GB, 76,458 of them
   under node_modules/).
2. Open a session in that directory in the Desktop app and run a turn long enough
   that the app stages a checkpoint (POST /api/session/<id>/revert/stage).
3. The request runs for tens of seconds; /api/info stops answering; the Desktop
   kills and restarts the CLI; the turn is aborted ("restart continuation"); repeat.

Additional Context

• Interrupted endpoints in my logs: GET /api/event (156x, the session event
  stream), POST /api/rpc/experimental.browser/attach (9x), GET /api/vcs/diff
  (7x), POST /api/session/<id>/revert/stage (4x), POST /api/worktree/refresh (2x).
• Workaround that stopped the loop immediately: add ignore rules for build
  artifacts (node_modules/, target/, .venv/, dist/, build/, caches) to the
  repo (both .gitignore and the snapshot view — note the snapshot repo uses its own
  git dir). Capture time dropped from 46.6 s to ~1.2 s and the service has now been
  running for hours without being replaced.
• Two secondary problems found in the same snapshot code, both worth hardening:
  • a file named nul in the work tree makes every capture fail with
    error: invalid path 'nul' / error: unable to add 'nul' to index /
    fatal: adding files failed (reserved device name on Windows; created by a
    Linux-side tool) — 10+ failures per minute while a turn was running;
  • a stale index.lock left in the snapshot repo caused permanent
    failed to capture snapshot failures (331 occurrences over two days) with no
    self-healing (see snapshot: corrupt index causes repeated capture failures and unresponsive service #42237).

OpenCode version

OpenCode Desktop 2.0.16 (Windows installer), bundled/managed CLI 2.0.16,
channel=latest

Operating System

Windows 11 22H2 (10.0.22621) x64

Terminal

Desktop app (Electron) — not a terminal session

Related issues

• core: session never drains when Snapshot.capture() stalls on huge untracked tree — git add hangs, execution claim never released #48657 — Snapshot.capture() stalls on huge untracked tree (root trigger; web/dev setup)
• snapshot: corrupt index causes repeated capture failures and unresponsive service #42237 — corrupt index causes repeated capture failures and unresponsive service
• cli: service becomes unresponsive under multi-session load — single process bottleneck #49095 — service becomes unresponsive under multi-session load
• cli: service restart can silently reuse an unresponsive incumbent #37795 — service restart can silently reuse an unresponsive incumbent