Repository navigation
desktop: file tree does not refresh live; workspace watcher emits no events (Windows) #56615
Description
Description
On Windows, the desktop Review panel's All files file tree does not update when files are created, modified, or deleted in the workspace. The server-side listing is correct (GET /api/fs/list includes the new file), but no watcher events are emitted for the workspace, so the UI is never notified to re-list and stays stale until a manual refresh (switching tabs / reopening the panel).
The workspace watcher is started with the node backend, while the (working) config-directory watcher uses the windows backend:
message="watcher started" path="D:\\recent\\tmp\\opencode_test" type=entries backend=node role=server
message="watcher started" path="C:\\Users\\<user>\\.config\\opencode" type=directory backend=windows role=server
Plugins
None (only a @opencode-ai/plugin dependency in ~/.config/opencode, no plugin entries configured).
OpenCode version
2.0.32 (desktop, channel latest; background service opencode-cli serve --service 2.0.32). Also reproduced on 2.0.29.
Steps to reproduce
- On Windows, open a workspace directory (a plain folder, no git repo needed) in the desktop app.
- Open the Review side panel and select the All files tab.
- Create / modify / delete a file in that workspace from a shell (or via the agent's file tools).
- Watch the file tree, and separately subscribe to
GET /api/event(SSE).
Expected behavior
New/renamed/removed files appear in the file tree without any manual refresh, and GET /api/event emits a file-change event for the workspace.
Actual behavior
No file events are emitted for the workspace at all, so the file tree does not refresh in real time and newly created files (e.g. c.txt, d.txt) are missing from the All files list.
Evidence collected while streaming GET /api/event:
- Creating, modifying, and deleting a file inside the workspace produced zero events.
- As a control, writing a file under
C:\Users\<user>\.config\opencodeimmediately producedskill.updatedevents for all locations (so the SSE stream and the config-dir watcher work). GET /api/fs/list?location[directory]=<workspace>returns the new file, so the data source is fresh — this is purely a "no live refresh" problem.
Note: the separate Files Changed counter is 0 here because the workspace is not a git repository (worktree discovery fails: Worktree.DirectoryUnavailableError), which is expected and unrelated — the file tree itself should still list files and refresh live.
OS
Windows 11 — Windows_NT 10.0.26200 (AMD64)
Terminal
Desktop app (Electron GUI), not a terminal. Shell used for the reproduction: cmd.exe / PowerShell 5.1.
Activity
opencode-agent commentedon Oct 18, 2026
Thanks for the detailed report and the
/api/eventdiagnostics. I think this is a duplicate of #52941.Your log line
type=entries backend=nodeis the key detail. In v2 the workspace watcher only watches a fixed set of names in the workspace root (the VCS branch metadata, like.git/HEAD). Nothing subscribes to the workspace directory itself, so creating, editing or deleting ordinary files never produces an event, and the file tree never gets told to re-list. This doesn't depend on Windows or on whether the folder is a git repo. Your config-directory control works because that path uses a full directory subscription (thewindowsbackend).Possible duplicates and related issues, ordered by likelihood:
filesystem.changed) references this issue.The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different. You're welcome to add your 2.0.32 findings to #52941.
opencode-agent commentedon Oct 19, 2026
We didn't hear back on how this differs from #52941, so I'm closing this as a duplicate of it. Both report the same problem: no workspace file-change events are emitted, so the desktop file tree doesn't refresh live.
Your 2.0.32 diagnostics are useful, especially the
type=entries backend=nodelog line and the empty/api/eventstream next to the working config-dir control. Please add them to #52941, where the fix is being tracked. If this turns out to be a different problem, reply here and we can reopen it. Thanks!