"Snapshot mechanism stalls on large workspaces: ~1min per git snapshot, permanent index.lock deadlock after a crash" #42597

Activity

1. fifaliao commented on Aug 14, 2026

   

   fifaliao

   on Aug 14, 2026

   Author

   More actions

   Set in the project opencode.json:

   { "snapshot": false }

   and delete any stale index.lock in the snapshot repo:

   C:\Users\<you>\.local\share\opencode\snapshot\<projectID>\<hash>\index.lock
   

   This restores normal interactivity but disables undo/redo for file changes.
2. github-actions

   assigned

   neriousy

   on Aug 14, 2026
3. github-actions commented on Aug 14, 2026

   

   github-actionsBot

   on Aug 14, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • Orphaned index.lock in snapshot gitdir causes blocking snapshot queue on Windows (Git Bash / mintty) #29413: Orphaned index.lock in snapshot gitdir causes blocking snapshot queue on Windows — same stale lock deadlock and snapshot queue blocking behavior on Windows
   • Snapshot git index.lock blocks LLM responses for 60+ seconds after crash #28952: Snapshot git index.lock blocks LLM responses for 60+ seconds after crash — same root cause (stale index.lock after crash) causing indefinite blocking
   • Desktop: snapshot's git add --sparse --pathspec-from-file=- hangs indefinitely blocked on stdin (not a zombie — process stays alive in Ss state) #41648: Desktop snapshot's git add --sparse --pathspec-from-file=- hangs indefinitely — related snapshot hang issue
4. CENFARG commented on Sep 30, 2026

   

   CENFARG

   on Sep 30, 2026

   More actions

   Adding data points from Windows 11 / opencode 1.18.33 (CLI + Desktop) — same snapshot pathology, with three extra findings that made it catastrophic and might help debugging.

   Environment: worktree is a Dropbox-synced docs tree with ~1.68M files across many nested git repositories.

   1. Two artifacts made every git add fail fatally, so the snapshot index was NEVER persisted — which turns the "~1 min per snapshot" into "full re-scan on every single agent step":

   • a nested git repository with zero commits (a stray git init that was never committed) → fatal: '<dir>/' does not have a commit checked out
   • a literal nul file (0 bytes, created by a > nul redirect from Git Bash) at the worktree root → fatal: invalid path 'nul'

   Both are invisible in opencode's log — the only symptom was generic slowness. Each failed add meant the next step re-scanned the whole tree again. One of these was created ~2 weeks before we diagnosed the slowness, which matches when symptoms started.

   2. The hang variant here is a CPU livelock, not a stdin block. Repeatedly observed a git parent/child pair where the parent sits at 0 CPU while the child spins at ~100% of one core for 5–15 minutes with exactly 0 bytes of I/O (Process IOReadBytes/IOWriteBytes = 0), holding index.lock. A second concurrent snapshot op then blocks at 0 CPU on the same lock. The command line matches the parent/child git add --all --sparse --pathspec-from-file=- --pathspec-file-nul shape from #41648, but with the opposite CPU signature (spin vs. sleep-on-stdin), so the stdin theory may only cover part of the failure space.

   3. Agent-facing symptom: "zombie" assistant messages with zero tokens. While the snapshot blocks the loop, the assistant message is created but no process/stream log lines ever appear, and the message is finalized (sometimes only when the instance closes) with tokens.output = 0 and no finish reason — no error logged at all. Measured instances: one turn hung for 1442s (24 min) and another for 391s producing nothing. From the user's perspective this looks exactly like a provider outage.

   Fix that worked here (after removing the two fatal artifacts): added the heavy subtrees to the worktree .gitignore (1.68M → 125k files), ran one clean git add directly in the snapshot repo to persist the index (3.7 MB), after which snapshot adds became incremental and fast (2.2s, 0 errors).

   Suggestions: (a) surface snapshot git add fatals in the log/UI instead of silently retrying full rescans forever, (b) skip embedded repos without commits the same way gitignored files are handled, (c) don't let the snapshot git add block the agent loop (async or bounded timeout).

   Related: #41648 (stdin-block variant, macOS), #29413 (orphaned index.lock on Windows).
5. thdxr commented on Oct 11, 2026

   

   thdxr

   on Oct 11, 2026

   Member

   More actions

   Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

   — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
6. thdxr

   closed this as not plannedon Oct 11, 2026