Repository navigation
Plugin loading intermittently hangs when .git directory exists (Windows) #25668
Description
Bug Description
When starting opencode in a directory that contains a .git folder, the plugin loading phase intermittently hangs indefinitely. The TUI shows "Loading plugins..." and becomes completely unresponsive (Ctrl+C doesn't work). This happens ~80% of the time in git-tracked project directories.
Reproduction Steps
- Install
oh-my-openagentplugin (a 130K-line bundled JS module) - Add to
opencode.json:"plugin": ["oh-my-openagent"] - Start opencode in any directory with a
.gitfolder - Observe: TUI shows "Loading plugins..." and hangs
Key Findings
- Without
.gitin the working directory -> always starts successfully - Without any plugin configured -> always starts successfully (even with
.git) - Both
.git+ plugin are required to trigger the hang - When it hangs, plugin JS code never begins executing - a
console.errorplaced at the very first line of the module (before any other code) does not produce output - The hang happens at the
await import(entry)stage in the plugin loader - When it does succeed, the full plugin loads normally with no issues
Environment
- OS: Windows 11 (build 26200)
- opencode: v1.14.33 (Bun-compiled binary)
- Embedded Bun: v1.3.13
- Plugin: oh-my-openagent v3.17.5 (~3.8MB bundled
dist/index.js, 130K lines) - Git: v2.x (even a tiny 3-commit, 0.07MB repo triggers it)
What We Tried
| Attempt | Result |
|---|---|
Set OMO_DISABLE_POSTHOG=true |
No effect (PostHog already disabled in code path) |
Hardcoded return NO_OP_POSTHOG in plugin |
No effect - JS never executes |
| Changed plugin spec to absolute file path | Slight improvement but still ~80% failure rate |
Changed plugin spec to file:// URL |
Same failure rate |
Created node_modules junction in project dir |
No effect |
| Cleaned SQLite database (177MB -> sessions removed) | No effect |
| Checkpointed and VACUUMed WAL (174MB) | No effect |
Renamed .git to _git_hidden |
100% success rate |
| Removed plugin from config | 100% success rate |
Root Cause Hypothesis
There appears to be a race condition in opencode's Bun runtime during plugin loading. When .git is present, opencode performs additional initialization (git status, project detection, session loading from SQLite) concurrently with the await import() of the plugin module. The combination of these concurrent operations causes the Bun runtime to deadlock or stall intermittently.
The fact that the JS module's top-level code never executes when hung suggests the issue is in the Bun import/evaluation pipeline itself, not in the plugin's JavaScript code.
Workaround
Open multiple terminal windows - one will eventually succeed. Alternatively, start opencode in a non-git directory first, then navigate to the project.
Activity
github-actions commentedon May 4, 2026
This issue might be a duplicate of existing issues. Please check:
If your issue is distinct (e.g. you are on a newer version where those are supposedly fixed, or the root cause differs), please add a note clarifying how this differs from the above.
Alfroul commentedon May 4, 2026
Update: Root Cause Identified
This issue is closely related to #25022. After extensive debugging, we traced the hang to the same root cause:
The hang occurs in
Project.fromDirectory(), not in the plugin loading itself. The UI shows "Loading plugins..." but the actual blocker is earlier — git subprocess calls during project directory initialization.Evidence matching #25022
console.errorat the very first line of the plugin module never produced output when hung → the Bun runtime never reachedimport()of the plugin.git→ 100% success rate (no git subprocess calls needed)Project.fromDirectory()likely completes before the UI checks ready state)Additional context from our debugging
.gitrepo triggers itDistinguishing factors
Our issue differs from #25022 in that it occurs on standard git repositories (not linked worktrees), and the trigger is the combination of
.gitpresence + large plugin loading happening concurrently withProject.fromDirectory().The fix described in #25022 (resolve worktree topology from on-disk metadata first, avoid git subprocesses) would likely resolve our case as well.
ukind commentedon May 8, 2026
this bug is very frustrating
Skypow2012 commentedon Jun 30, 2026
I've encountered it too.
github-actions commentedon Aug 30, 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.