Repository navigation
Windows: snapshot indexer stalls on a large untracked tree in $HOME - opencode run hangs and never creates a session #57841
Description
Description
opencode run hangs indefinitely when the working directory is the user's home directory on Windows, and never creates a session. The home directory is a git work-tree, and OpenCode's snapshot indexer streams every untracked path into a single git update-index before the model is contacted.
The Windows-specific amplifier is the legacy shell junctions in $HOME (Application Data, Local Settings, Cookies, My Documents, SendTo, Start Menu, Templates, Web, WebComponents). Each re-exposes AppData (1,039,918 files here) as a separate top-level tree, so git walks the same content repeatedly and ~1.13M paths are handed to the indexer.
Measured on the affected machine:
| files | time | |
|---|---|---|
git ls-files --others --exclude-standard (before) |
1,126,526 | 84.67s |
same, after adding a .gitignore |
5,325 | 0.36s |
opencode run (before) |
— | never completes |
opencode run (after) |
— | 7.1s |
Plugins
none — no global or project-local plugins installed
OpenCode version
2.1.2 (channel latest, global npm install)
Steps to reproduce
- Make
$HOMEa git work-tree with no commits and no.gitignore:
cd ~ && git init - From
$HOMErun:opencode run "hello" - Observe: the process stays alive with no stdout, no error, and no session row is written to
opencode.db(session/session_v2unchanged). Read-only subcommands (opencode models,opencode debug config) return instantly.
The blocking call is visible in ~/.local/share/opencode/log/opencode.log:
message="spawning process" command="C:\Program Files\Git\cmd\git.EXE" args="[\"--git-dir\",\"C:\\Users\\<user>\\.local\\share\\opencode\\snapshot\\global\\<hash>\",\"--work-tree\",\"C:\\Users\\<user>\",\"update-index\",\"--add\",\"--remove\",\"--replace\",\"-z\",\"--stdin\"]"
A child git.exe update-index --add --remove --replace -z --stdin stays resident at ~99% CPU (>207s CPU time observed, still running after 5+ minutes) and holds index.lock in the snapshot repo. No provider request is ever made.
Screenshot and/or share link
No screenshot — reproduces deterministically with the steps above.
Operating System
Windows 11 Home Single Language 10.0.26200 (build 26200), x64
Terminal
PowerShell 7.6.7 (pwsh), TERM / TERM_PROGRAM unset
Notes
- Same root cause as core: session never drains when Snapshot.capture() stalls on huge untracked tree — git add hangs, execution claim never released #48657, with three differences worth recording: Windows rather than Darwin; OpenCode 2.1.2 rather than a 2.0.2 dev checkout, where the command is
git update-index --add --remove --replace -z --stdinrather thangit add --all --sparse --pathspec-from-file=-; and a 6.7x larger untracked set (1.13M vs 167k) because the legacy junctions re-exposeAppDataas nine extra trees. - Related: service: background server boots the user home directory as a location #49209 (background service boots
$HOMEas a location) andopencode runintermittently hangs during init — no session created, no output, no error (~56% failure rate observed) #38723 (opencode runhangs during init, no session created). - Workaround confirmed: add a
.gitignoreto$HOMEcoveringAppData/, the legacy junction dirs, tool state and caches — the untracked set drops to 5,325 files andopencode runcompletes in 7.1s.snapshot: falsealso avoids the path entirely. - Possible fix directions (suggestion only): skip or cap the snapshot index when the working directory is
$HOME; treat legacy Windows junctions as excluded; or bound/timeout the untracked-path enumeration so a pathological tree degrades tosnapshot: undefinedinstead of blocking session startup.
Activity
[-]Windows: legacy \C:\Users\PARDHU junctions inflate the snapshot pathspec set ~9x - \opencode run\ in \C:\Users\PARDHU hangs and never creates a session[/-][+]Windows: legacy $HOME junctions inflate the snapshot pathspec set ~9x - opencode run in $HOME hangs and never creates a session[/+]opencode-agent commentedon Oct 21, 2026
Thanks for the detailed measurements and the confirmed workaround. I think this is a duplicate of #48657: the snapshot capture walks the whole untracked tree in
$HOMEand hands every path to one git command, so the session blocks before the provider is ever contacted. The Windows legacy junctions make the tree much bigger, but the cause is the same, and the fix #48657 asks for (bounding, timing out or skipping a pathological capture) would cover this too. I see you've already added these findings there, which helps.Possible duplicates and related issues, ordered from most to least likely:
.gitin the home folder)$HOMEas a locationopencode runintermittently hangs during init — no session created, no output, no error (~56% failure rate observed) #38723:opencode runhangs during init with no session created (v1, different cause: stdin/network)Until this is fixed, a
.gitignorein$HOMEcoveringAppData/and the legacy junction folders, orsnapshot: false, avoids the hang, as you found.The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different.
Vijayapardhu commentedon Oct 21, 2026
Thanks for the triage — agreed, this is a duplicate of #48657 (and of #32981 for the home-directory case), and closing is right. Two things worth passing on before it does, including a correction to my own report.
Correction to my title. I claimed the legacy
$HOMEjunctions (Application Data,Local Settings,Cookies, …) inflate the pathspec set ~9x. That is wrong — they are NTFS junctions and git does not traverse them:git ls-files --others --exclude-standard -- "Application Data"returns 0 paths.AppDataitself is 1,039,918 of the 1,126,526 paths (92%); the junctions contribute nothing. Please disregard the "9x" framing and the suggestion to exclude them — that would not change the path count.New data, and a portable reproduction that needs no large home directory. Scratch git repo, 200,000 untracked empty files, OpenCode 2.1.2 / Windows 11 / stdin closed, same command and provider both runs:
opencode runwall clockbulk/presentbulk/to.gitignoreA 52x difference with nothing else changed, and the provider is not contacted until the capture finishes. This reproduces outside
$HOMEentirely, so it is independent of the home directory, of the junctions, and of the provider.That is a threshold datapoint in the form #48657 asks for ("cap/skip capture when the untracked candidate set exceeds a threshold"): ~200k untracked paths already adds ~4 minutes to every session start, and the cost scales roughly linearly with the untracked count. The machine in my original report reaches 1,126,526 paths (84.67s for
ls-filesalone) andupdate-indexnever completes — >207s CPU observed, still running after 5+ minutes,index.lockheld — at which pointopencode rundoes not return at all.Other facts confirmed on 2.1.2 / Windows: the blocking call is
git update-index --add --remove --replace -z --stdin(same form as @cyanyux's 2.0.32 comment above), it holdsindex.lockin the snapshot repo, and no provider request is made until it returns. Workarounds confirmed on Windows: a.gitignorecoveringAppData/, tool state and caches, orsnapshot: false.Full detail, the correction, and the reproduction are being cross-posted to #48657 so nothing is lost when this is closed.
[-]Windows: legacy $HOME junctions inflate the snapshot pathspec set ~9x - opencode run in $HOME hangs and never creates a session[/-][+]Windows: snapshot indexer stalls on a large untracked tree in $HOME - opencode run hangs and never creates a session[/+]opencode-agent commentedon Oct 22, 2026
Closing this as a duplicate of #48657, since we haven't heard that your problem is different. The hang you measured is the same one tracked there: snapshot capture passes the whole untracked
$HOMEtree, here made much bigger by the Windows legacy junctions, to a single git command before the model is ever contacted. Your Windows findings are already on #48657, so please follow that issue for updates.Until it's fixed, a
.gitignorein$HOMEcoveringAppData/and the junction folders, orsnapshot: false, avoids the hang. If this turns out to be a different problem, reply here with the details and we can reopen it. Thanks for the thorough report!