server: silent service restarts within seconds of git worktree add — tool responses lost, worktree registry stale #58991

Summary

The opencode serve --service process was silently killed and restarted 4 times within ~45 seconds (plus once more later in the session), each restart landing 6–9 seconds after a git worktree add spawned by the worktree_create tool or by a server-side shell. In-flight tool calls return "Tool execution interrupted", no error is logged at the death boundary, and after reboot the worktree registry is stale (worktrees exist on disk but are invisible to worktree_list, causing duplicate suffixed worktrees on retry).

Environment

• opencode version: v2.1.0
• OS: Windows_NT 10.0.26300 (win32 x64)
• Terminal: TERM_PROGRAM=herdr, TERM=xterm-256color, COLORTERM=truecolor (herdr wrapper; service.json present in config — service is supervised/restarted externally)
• Shell: PowerShell 7 (pwsh) for tool execution; COMSPEC=cmd.exe
• Install/channel: latest (update notice 2.1.0 → 2.1.4 was present, but every restarted run stayed on 2.1.0 — not an auto-update)
• Active plugins: none found (opencode.jsonc has no plugin entries; no .opencode/plugin/)

Reproduction

1. Run opencode serve --service against a large git checkout (thousands of files) with an active session.
2. From a session, call worktree_create three times concurrently (Promise.all) for three new worktree names.
3. Observe: the tool returns {"error":"aborted","message":"Tool execution interrupted: execute"}, followed within seconds by the harness message "The server restarted while you were working." The log shows the old run's lines stop abruptly (last line: watcher churn) with no ERROR/FATAL/panic, then a new run logs cli starting ... args=["serve","--service"] ~6 s later, answering 503 for ~1 s while booting.
4. Repeat (a retry batch, then a single worktree_create): same pattern — 4/4 attempts correlated with restarts. A plain server-side shell git worktree add also coincided with a restart once; other shell worktree commands did not — so it is intermittent, not deterministic.
5. After each reboot, worktree_list does NOT show the worktrees that exist on disk (git worktree list shows them, detached). Retrying the create yields name-2, name-3 duplicates because the tool's registry didn't know the directory already existed.

Expected Behavior

worktree_create returns its result; repo worktree operations never restart the service; after any restart the worktree registry matches git worktree list.

Actual Behavior

• Restarts at 2026-10-25T07:19:23.8, 07:19:38.3, 07:19:56.3 UTC (run IDs cf73ddba → 3b02fac7 → f01e259d → 4d312f54; the killed run had ~3.67 days uptime) plus one more during a later shell git worktree add chain.
• Deaths are silent: no log line above INFO at any boundary; the log simply stops, and a supervisor externally relaunches the same version.
• All git worktree add processes DID complete server-side — only the tool responses were lost. Callers saw "aborted" for work that had succeeded.
• Registry desync persisted after reboot → duplicate worktrees, lost responses, at-risk background subagents.

Additional Context

• Log file: ~/.local/share/opencode/log/opencode.log; search run=cf73ddba, run=3b02fac7, run=f01e259d, run=4d312f54 around 07:19:17–07:20:02 for the full sequence (cli starting lines mark each reboot).
• The recurring WARN flood failed to list MCP resource templates server=zotero-mcp ... Method not found appears on every boot and seems unrelated (present during healthy periods too).
• Frequency: 4 in ~45 s, then stable for the remainder of a multi-hour session (heavy test suites and shell git ops ran fine). Two earlier single worktree_create calls completed without incident, so triggering is intermittent.
• Impact: interrupted orchestration, lost tool responses, potential orphaned background subagent sessions, duplicate worktree dirs.
• Workaround adopted: after any worktree operation, reconcile with git worktree list and checkout -B; avoid concurrent worktree_create; treat "aborted" worktree creates as possibly-succeeded before retrying.
• Hostnames/usernames/repo paths redacted; no secrets included.