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

Description

On a large git workspace (~5,300 tracked files) running opencode 1.18.18 on Windows, the project snapshot mechanism becomes pathological:

1. Every agentic iteration triggers a full git add -A + git commit inside a custom snapshot repository. On a large workspace each of these takes ~1 minute (git add -A ≈ 57s, git commit ≈ 19s measured locally), so every single model interaction is blocked for ~1 minute before anything is sent.
2. When a snapshot git process crashes (or is killed), it leaves a stale index.lock in the snapshot repository. From then on, every snapshot operation fails with fatal: Unable to create '...index.lock': File exists and opencode retries indefinitely — memory balloons to 6–8 GB, disk reads exceed 10 GB, and no response is ever produced. The only fix is to manually delete the index.lock file.

Plugins

No response

OpenCode version

1.18.18

Steps to reproduce

1. Open a large repo (several thousand tracked files) in opencode on Windows.
2. Verify the snapshot git repo under ~/.local/share/opencode/snapshot/<projectID>/...:
   • Run git add -A in that repo → observe tens of seconds.
   • Run git commit → same.
3. Trigger a snapshot operation and then kill the opencode process mid-operation → a stale index.lock is left behind.
4. Restart opencode in the same directory → every interaction now logs:

   WARN level=WARN message="failed to add snapshot files" exitCode=128
   stderr="fatal: Unable to create '.../snapshot/.../index.lock': File exists.
   Another git process seems to be running in this repository..."
   

   The session becomes unresponsive: ~6–8 GB RSS, continually increasing disk reads, and no answer is returned, because snapshot never succeeds and opencode retries forever.

Screenshot and/or share link

No response

Operating System

windows

Terminal

No response