Repository navigation
Desktop: snapshot's git add --sparse --pathspec-from-file=- hangs indefinitely blocked on stdin (not a zombie — process stays alive in Ss state) #41648
Description
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.lockin the snapshot git-dir (confirmed vialsof) --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 staleindex.lockunblocks the current turn, but recurs on retry for the same project- Setting top-level
"snapshot": falseinopencode.jsoncavoids 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)
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Aug 11, 2026
This issue might be related to an existing open issue not mentioned above:
git add --all --sparse --pathspec-from-file=- --pathspec-file-nulcommand 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 commentedon Aug 11, 2026
Checked — this is not the same root cause as #39388.
.gitin the project is a real directory, not a worktree pointer filegit rev-parse --git-dir --git-common-dirreturn identical paths (.git/.git) — in a linked worktree these would differgit worktree listshows 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.github-actions commentedon Oct 11, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.