You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
TUI crash: ENOSPC: no space left on device, watch '/home/user/.local/state/opencode/beta/tui' #48384
The OpenCode TUI crashed with an unexpected error.
Error: ENOSPC: no space left on device, watch '/home/capcu/.local/state/opencode/beta/tui'
Stack trace:
Error: ENOSPC: no space left on device, watch '/home/capcu/.local/state/opencode/beta/tui'
at watch (unknown)
at new FSWatcher (internal:fs/watch:101:31)
at watch (internal:fs/watch:172:23)
at FBt (/$bunfs/root/chunk-95xq6bqn.js:2690:3519)
at nre (/$bunfs/root/chunk-95xq6bqn.js:2690:3687)
at Vr (/$bunfs/root/chunk-jkcty1et.js:2:7136)
at <anonymous> (/$bunfs/root/chunk-95xq6bqn.js:2590:3413)
at <anonymous> (/$bunfs/root/chunk-jkcty1et.js:2:14778)
at Qe (/$bunfs/root/chunk-jkcty1et.js:2:10136)
at dA (/$bunfs/root/chunk-jkcty1et.js:2:9916)
Plugins
No response
OpenCode version
0.0.0-beta-19271
Steps to reproduce
Reported automatically from the OpenCode crash screen. If you can, describe what you were doing when it crashed.
Counting inotify descriptors and watch entries under /proc/*/fdinfo showed:
TOTAL instances=24 watches=524250
524202 watches 3 instances opencode2 serve --service
One inotify FD owned by the existing OpenCode service contained 524,129 watches by itself. The service command was:
.../.opencode2-wrapped serve --service
There was only one OpenCode service plus its client wrapper running. Launching a second opencode2 TUI then reproduced the crash exactly:
ENOSPC: no space left on device, watch '/home/capcu/.local/state/opencode/beta/tui'
at new FSWatcher (internal:fs/watch:101:31)
The system journal also showed unrelated processes (systemd user services, Chromium, tmux scopes, GNOME Keyring) failing to add inotify watches with No space left on device, confirming that OpenCode had exhausted the user-wide kernel watch pool.
So the likely failure mode is that the long-running Bun-based OpenCode service accumulates/leaks recursive filesystem watches until it reaches fs.inotify.max_user_watches. The next OpenCode instance is merely where the exhausted limit becomes visible. Restarting the service releases those watches, which explains why that temporarily fixes it.
Environment: OpenCode 0.0.0-beta-19271, Linux 6.18.44 x64, system Bun 1.3.13 (though OpenCode's embedded Bun version may differ).
Thanks for the report and the detailed inotify investigation! Version 2.0.17 fixed this specific TUI storage-watcher crash: if the watch limit is exhausted, OpenCode now disables cross-instance settings refresh instead of crashing, though that does not itself resolve the underlying watch exhaustion. Update with opencode upgrade or npm i -g @opencode/cli@latest (desktop: update the app). Please reopen or comment if this storage-watcher crash still happens on that version or newer.
Activity
dtvillafana commentedon Sep 10, 2026
killing the opencode2 server and restarting it clears this issue, but it keeps coming back.
I had 800GB of space left, so this error was lying.
dtvillafana commentedon Sep 10, 2026
additional context, I had one instance of opencode2 running, but this error appears when I launch a second.
russrapper15-png commentedon Sep 10, 2026
fbadcode-Q_GkBRB54g5kT_txNy5r9ddARq546WNRNDLqbMkNj8cq470I-C_LqQFWiDlb3lhWoWVf
dtvillafana commentedon Sep 11, 2026
after running into a similar issue with both bun and yarn in separate projects, it might be related to bun or yarn or whatever is common between them.
dtvillafana commentedon Sep 14, 2026
I investigated this at the OS level and confirmed that this is inotify watch exhaustion, not disk exhaustion.
Diagnostics while the issue was active:
Counting inotify descriptors and watch entries under
/proc/*/fdinfoshowed:One inotify FD owned by the existing OpenCode service contained 524,129 watches by itself. The service command was:
There was only one OpenCode service plus its client wrapper running. Launching a second
opencode2TUI then reproduced the crash exactly:The system journal also showed unrelated processes (systemd user services, Chromium, tmux scopes, GNOME Keyring) failing to add inotify watches with
No space left on device, confirming that OpenCode had exhausted the user-wide kernel watch pool.So the likely failure mode is that the long-running Bun-based OpenCode service accumulates/leaks recursive filesystem watches until it reaches
fs.inotify.max_user_watches. The next OpenCode instance is merely where the exhausted limit becomes visible. Restarting the service releases those watches, which explains why that temporarily fixes it.Environment: OpenCode
0.0.0-beta-19271, Linux 6.18.44 x64, system Bun1.3.13(though OpenCode's embedded Bun version may differ).neriousy commentedon Oct 20, 2026
Thanks for the report and the detailed inotify investigation! Version 2.0.17 fixed this specific TUI storage-watcher crash: if the watch limit is exhausted, OpenCode now disables cross-instance settings refresh instead of crashing, though that does not itself resolve the underlying watch exhaustion. Update with
opencode upgradeornpm i -g @opencode/cli@latest(desktop: update the app). Please reopen or comment if this storage-watcher crash still happens on that version or newer.