watcher: fs watcher subscribes/unsubscribes skill directories in a tight loop (100%+ CPU, macOS) #53811

Activity

1. github-actions

   assigned

   nexxeln

   on Oct 7, 2026
2. opencode-agent commented on Oct 7, 2026

   

   opencode-agentBot

   on Oct 7, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed report and the A/B numbers.

   We tried to reproduce this on 2.0.24 on Linux with the same layout: ~/.claude/skills and ~/.agents/skills, plus .claude/skills and .agents/skills in a project. We ran opencode serve from $HOME and opened both the project and $HOME. On Linux each skill directory was watched once and never re-subscribed, and CPU stayed near zero. Your samples are all inside the macOS FSEvents watcher, so this looks specific to macOS. It needs a maintainer with a Mac to check further.

   Two things would help:

   • Does the loop also happen with plain opencode serve (without OpenChamber) from $HOME on macOS?
   • During the churn, does anything get written under ~/.config/opencode (for example, plugin state or log files)? A write anywhere in that directory can trigger the same skill-watcher re-subscribe cycle; see core: any file write inside the config directory triggers an un-debounced compatibility reload — ~/.claude/skills watcher resubscribe loop (v2.0.23) #53393.

   Related issues, ordered by likelihood:

   • server: file watcher restarts in a loop on unmodified skill directories, dropping SSE and respawning the CLI #53416: the same endless watcher restart loop on unmodified skill directories, on Windows
   • core: any file write inside the config directory triggers an un-debounced compatibility reload — ~/.claude/skills watcher resubscribe loop (v2.0.23) #53393: any write inside the global config directory re-subscribes the skill watchers; PR fix(core): skip compatibility reloads for unrelated config writes #53764 addresses it
   • serve: file watcher re-registration storm during bulk skills writes terminates service process #50594: a watcher re-registration storm on ~/.claude/skills, with high idle CPU over time
   • opencode serve pegs CPU at ~1000% — fff content-indexes entire $HOME (search.ts enableHomeDirScanning/FsRootScanning) #32511: high CPU from the file indexer when the server runs from $HOME, which may also apply to your setup

   Until then, OPENCODE_DISABLE_FILEWATCHER=1 remains the workaround, as you found.
3. bbruen3 commented on Oct 7, 2026

   

   bbruen3

   on Oct 7, 2026

   Author

   More actions

   Thanks — both answers:

   Plain opencode serve (no OpenChamber) from $HOME, macOS: no loop. v2.0.21 opencode serve with SSE clients on $HOME and a project stayed ~0.5% CPU, while the client-driven server on the same machine was at ~67% over the same window. So plain serve alone does not reproduce for me.

   Writes under ~/.config/opencode during churn: none. I monitored the config root, ~/.config/openchamber, and ~/.local/state/opencode for 30s during active churn: 0 changes. So #53393's write-trigger isn't active here — this looks like the zero-activity variant in #53416.

   Consolidating all skill roots to one real dir cut it ~4× (CPU 288% → ~50%, log lines 1701/4s → 408/4s) but did not stop it — still looping over 3 watched paths (one global canonical dir plus the project's .claude/skills and .agents/skills). The watcher is left enabled.

   Given the overlap, this may be the macOS instance of #53416.
4. Gladess1102 commented on Oct 18, 2026

   

   Gladess1102

   on Oct 18, 2026

   More actions

   Confirming this still happens on 2.0.32 (desktop app, bundled opencode-cli 2.0.32), and adding a variant of the loop plus two side effects that I didn't see mentioned here.

   Different failure mode: subscribe fails instead of churning

   In my case the loop is driven by subscribe errors rather than successful resubscribes. Same root, different entry point:

   message="watcher subscribe" path=<project>/.agents/skills
   level=ERROR message="failed to subscribe" directory=<project>/.agents/skills
     cause="Error: Error starting FSEvents stream
       at ConfigSkillPlugin.watch
       at ConfigSkillPlugin.load
       at ConfigSkillPlugin.refresh
       at Effect.fn"
   message="watcher stopped" path=~/.agents/skills
   message="watcher subscribe" path=~/.agents/skills   <-- immediately again
   

   Two things worth noting:

   • The failing path is fine. While the loop was running I called fs.watch() on the exact same directory from a separate Node process and it succeeded (all four skill roots, including the one that was failing). So the original error is transient — it's the retry behaviour that makes it permanent.
   • A failure on one directory also tears down and recreates watchers for the other directories, so one bad path keeps resetting all of them.

   Impact

   Metric	Idle	During the loop
   opencode-cli CPU	~2%	158%
   opencode-cli RSS	~800 MB	1660 MB
   macOS compressor	1.5 GB	4.5 GB
   system CPU idle	~80%	0.8%

   failed to subscribe appeared 3796 times in one session (roughly 1–3/s at peak). The machine was unusable — not just high CPU, but memory pressure pushing everything else into swap.

   RSS did come back down (~816 MB) once the loop stopped on its own, so I don't think this is a permanent leak — but the balloon is large enough to take a 16 GB machine down while it lasts.

   Quitting the desktop app does not clear it

   opencode-cli serve --service survives app quit as an orphan (PPID 1) and keeps the elevated RSS. Relaunching the app reconnects to that same orphan, so restarting the app looks like it does nothing. Only pkill -f "opencode-cli serve --service" clears it. Might be worth handling separately — it makes this bug much harder to get out of.

   Trigger

   Same as yours: multiple project directories open, several skill roots. Mine appeared spontaneously after long uptime. OPENCODE_DISABLE_FILEWATCHER=1 sounds like the right workaround — thanks for finding it, I'll use that.

   Happy to provide the raw log window or a sample if useful. macOS 26.5.1 / M1 / 16 GB.