EMFILE: too many open files, watch 'home/user/.local/state/opencode/latest/tui' #50566

Activity

1. github-actions

   assigned

   kommander

   on Sep 22, 2026
2. github-actions commented on Sep 22, 2026

   

   github-actionsBot

   on Sep 22, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Opencode hangs at startup if a .git repo is present and inotify user instances run out #16610: Same root cause — EMFILE (too many open files) when OpenCode tries to watch files using inotify at startup. That issue includes a workaround: increase the inotify user instances limit with sudo sysctl -w fs.inotify.max_user_instances=2048.

   👍React with 👍1Reacted by Julian Calzada
3. juliancalzada

   changed the title [-]EMFILE: too many open filees, watch 'home/user/.local/state/opencode/latest/tui'[/-] [+]EMFILE: too many open files, watch 'home/user/.local/state/opencode/latest/tui'[/+] on Sep 22, 2026
4. CGuiho commented on Oct 4, 2026

   

   CGuiho

   on Oct 4, 2026

   More actions

   I've got it today.

   👍React with 👍1Reacted by Julian Calzada
5. gandb commented on Oct 21, 2026

   

   gandb

   on Oct 21, 2026

   More actions

   The same here:

   Error: EMFILE: too many open files, watch '/home/gandb/.config/opencode'
   at watch (unknown)
   at new FSWatcher (internal:fs/watch:101:31)
   at watch (internal:fs/watch:172:23)
   at Dpe (/$bunfs/root/chunk-e5561drs.js:3:55263)
   at Ri (///root/chunk-s6m57scs.js:2:6899)
   at get (///root/chunk-s6m57scs.js:2:17800)
   at children (///root/chunk-pa6pb7e8.js:2590:3713)
   at (///root/chunk-s6m57scs.js:2:14480)
   at je (///root/chunk-s6m57scs.js:2:9876)
   at K (///root/chunk-s6m57scs.js:2:9657)

   Error: EMFILE: too many open files, watch '/home/gandb/.config/opencode'
   Stack trace:
   Error: EMFILE: too many open files, watch '/home/gandb/.config/opencode'
       at watch (unknown)
       at new FSWatcher (internal:fs/watch:101:31)
       at watch (internal:fs/watch:172:23)
       at Dpe (/$bunfs/root/chunk-e5561drs.js:3:55263)
       at Ri (/$bunfs/root/chunk-s6m57scs.js:2:6899)
       at get (/$bunfs/root/chunk-s6m57scs.js:2:17800)
       at children (/$bunfs/root/chunk-pa6pb7e8.js:2590:3713)
       at <anonymous> (/$bunfs/root/chunk-s6m57scs.js:2:14480)
       at je (/$bunfs/root/chunk-s6m57scs.js:2:9876)
       at K (/$bunfs/root/chunk-s6m57scs.js:2:9657)
   Additional context: This error appeared inside the orca app when opencode is triggered from there. The issue occurs specifically when using OpenCode within the orca application environment.
   Environment:
   - OpenCode version: 2.1.2
   - OS: Linux 7.0.0-38-generic (x64)
   - Terminal: Orca 1.4.235
   Reproduction: Is intermitent, but some hours using orca is possible to reproduce.
   
   1. Install orca from https://www.onorca.dev/download  
   2. Use some hours opencode into the IDE
   
   ---
   You can now copy this text and paste it into the GitHub issue form at the URL that was opened in your browser. The form should be pre-filled with the template and title, and you just need to paste the body and submit.
   
   ### Plugins
   
   _No response_
   
   ### OpenCode version
   
   2.1.2
   
   ### Steps to reproduce
   
   Reported automatically from the OpenCode crash screen. If you can, describe what you were doing when it crashed.
   
   ### Screenshot
   
   _No response_
   
   ### Operating System
   
   Linux 7.0.0-38-generic (x64)
   
   ### Terminal
   
   Orca 1.4.235
   
6. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   Contributor

   More actions

   Thanks for the report! I think this is a duplicate of #51208. In 2.0.12 the TUI watched its state directory (~/.local/state/opencode/<channel>/tui) with fs.watch and didn't handle errors. So when the system ran out of inotify instances (EMFILE), the whole TUI crashed instead of just turning off live-reload.

   Possible duplicates and related issues, ordered by likelihood:

   • tui: crashes with ENOSPC when inotify watch limit is exhausted #51208: the same unguarded watcher on state/opencode/.../tui crashing the TUI (reported with ENOSPC), fixed by fix(tui): don't crash when fs.watch throws (e.g. ENOSPC) #51210 and fix(tui): handle storage watcher errors after startup #51243
   • tui: startup crash with EMFILE when inotify instances are exhausted (unguarded fs.watch in ConfigProvider) #51489: the same crash on ~/.config/opencode (the variant @gandb hit on 2.1.2), fixed by fix(tui): degrade gracefully when fs.watch fails #51536
   • Opencode hangs at startup if a .git repo is present and inotify user instances run out #16610: an older report of inotify EMFILE at startup

   As of v2.1.4, all TUI file watchers handle this error: a watch that fails disables live-reload instead of crashing the TUI. Please upgrade to v2.1.4 or later.

   If you hit this before you can upgrade, either of these should help:

   • Raise the inotify limit: sudo sysctl -w fs.inotify.max_user_instances=2048
   • Or, on v2.1.4 or later, turn off file watching with OPENCODE_DISABLE_FILEWATCHER=1

   The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different, for example if it still happens on v2.1.4 or later.
7. opencodejr

   added

   pending close

   triaging

   on Oct 28, 2026
8. opencodejr

   closed this as duplicateon Oct 29, 2026
9. opencodejr commented on Oct 29, 2026

   

   opencodejrBot

   on Oct 29, 2026

   Contributor

   More actions

   Closing this as a duplicate of #51208, since we haven't heard back. This crash came from the TUI's fs.watch on ~/.local/state/opencode/<channel>/tui not handling inotify exhaustion (EMFILE). #51210, #51243 and #51536 fixed it: as of v2.1.4, a watch that fails just disables live-reload instead of crashing the TUI. The related ~/.config/opencode variant is tracked in #51489.

   Please upgrade to v2.1.4 or later. If you still see this crash on v2.1.4 or later, comment here with your version and the stack trace and we'll take another look. Thanks for the report!