Desktop: snapshot's `git add --sparse --pathspec-from-file=-` hangs indefinitely blocked on stdin (not a zombie — process stays alive in `Ss` state)

[v0id-byte]

Environment

• OpenCode Desktop v1.18.15 (Electron, packaged), macOS
• Custom OpenAI-compatible provider (self-hosted llama.cpp), but confirmed unrelated to backend (see below)

Description

When running an agent task in a specific project, the Desktop UI gets stuck in "thinking" indefinitely. Root cause is a hung local git subprocess spawned by the snapshot/checkpoint feature — the LLM backend itself has already finished responding.

Reproduction (3/3 times, immediately, on this project)

ps -o pid,etime,time,stat,command -p <pid>
  ELAPSED   TIME STAT COMMAND
  14:19    0:01  Ss   git -c core.autocrlf=false -c core.longpaths=true -c core.symlinks=true \
    --git-dir /Users/.../.local/share/opencode/snapshot/<hash1>/<hash2> \
    --work-tree /Users/.../project \
    add --all --sparse --pathspec-from-file=- --pathspec-file-nul

• Process is alive (Ss, sleeping/session-leader) — not a zombie/defunct child like opencode -c/-i TUI sessions hang permanently: zombie git child under project-copy-refresh snapshot step #40439
• Near-zero CPU time (0:01-0:00.78) across 14+ minutes elapsed — genuinely blocked, not slow
• Holds an open index.lock in the snapshot git-dir (confirmed via lsof)
• --pathspec-from-file=- reads the pathspec list from stdin; process appears blocked waiting for EOF on stdin that never arrives
• Reproduced identically 3 times in a row, immediately after each retry, on the same project (~4200 files, 40MB, no unusual filenames/symlinks)

Confirmed NOT backend-related

Correlated with server-side request logs during the hang: the model had already finished generating (task released, GPU utilization back to 0%) while the Desktop UI still showed "thinking" — the hang is entirely in the local snapshot step, after the LLM response.

Workaround

• kill <pid> + remove the stale index.lock unblocks the current turn, but recurs on retry for the same project
• Setting top-level "snapshot": false in opencode.jsonc avoids the bug entirely (loses undo/revert capability) — this is what we ended up doing

Possibly related

#40439, #36370, #32981, #29413 - all snapshot-step hangs, but none match this exact symptom (live process blocked on stdin, not a zombie, not sidecar-stream-related, not Windows-specific)

[github-actions]

This issue might be related to an existing open issue not mentioned above:

• Snapshot seeding hangs in git linked worktrees (copied index is the main repo's) #39388: "Snapshot seeding hangs in git linked worktrees" — also shows the exact same git add --all --sparse --pathspec-from-file=- --pathspec-file-nul command hanging indefinitely, though the diagnosed root cause there is a wrong index being copied in linked-worktree setups rather than a stdin-close issue. Worth checking if the underlying stdin pipe handling is the shared root cause across both.

If your project happens to use git linked worktrees, #39388 may be the same bug. If not, these are likely distinct root causes with the same hung git subprocess as the symptom.

[v0id-byte]

Checked — this is not the same root cause as #39388.

• .git in the project is a real directory, not a worktree pointer file
• git rev-parse --git-dir --git-common-dir return identical paths (.git / .git) — in a linked worktree these would differ
• git worktree list shows a single entry (itself)

So the "wrong index copied from the main repo" explanation in #39388 doesn't apply here — there's no worktree involved.

Symptom also doesn't match: #39388's hung process is CPU-bound (650% CPU, actively re-hashing a huge repo — makes sense given chromium-scale file counts). Ours sits at ~0.01s CPU time over 14+ minutes elapsed, on a small project (~4200 files / 40MB) — genuinely blocked, not doing slow work.

Both bugs happen to surface via the same outer command (git add --all --sparse --pathspec-from-file=- --pathspec-file-nul), since that's the standard snapshot-seeding invocation — but the two failure paths look distinct: #39388 is a worktree-index mismatch causing needless CPU-bound rehashing, this one is a stdin pipe that never gets closed, causing an indefinite blocking read with the process otherwise idle.