Manual Refresh the File Tree

[chen1plus]

This issue has been neglected for a significant period. I have compiled the relevant data and community frustration to highlight why this can no longer be ignored.

Zed relies on system file events to refresh the file tree. While it's elegant in theory, it ignores a vast array of real-world development environments. There is an overwhelming demand for this within the community.

• Duplicate issues: Support for manually refreshing projects when inotify/fsevents unavailable (e.g. on nfs file shares) #20044 Remote Development: Files not updated #25740 Zed does not detect changes to NFS mounts #27227 Remote Workspace File Tree (Left Dock) does not refresh when changes to the file structure are made #29242 Manual refresh on unsupported filesystems (nfs, fuse, exfat) without inofity/fsevents #29598
• PRs: Add command to manually trigger a refresh/rescan of folders #46291 project_panel: Add "rescan worktrees" action #48871

This issue primarily plagues users in cluster environments. Any system utilizing shared filesystems is inherently susceptible to this failure. This is a fundamental limitation that even VS Code cannot solve through automation alone, as these environments offer no guarantee that the operating system will provide file change notifications.

Theoretically, the root cause lies within the cluster system. But should I be forced into a two-year standstill just to wait for an admin to fix it? In the world of HPC, file system level changes are non-negotiable. Breaking the file system means breaking the workflow for thousands of users.

Community Disconnect & Development Culture

I apologize first, because I was a bit angry while writing this discussion, and I hope I haven't offended anyone.

Beyond the technical bug, there is a more concerning trend in how this issue is being handled. The PR (#46291) has been met with dismissive closures based on architectural purity. Here's several concerns:

• We have proposed middle-ground solutions, but they are ignored without substantive feedback.
• Technical purity is being prioritized over user utility. A tool that refuses to provide a fallback for its own limitations is a tool that ceases to serve its community.
• When 30+ upvotes and multiple redundant issues are disregarded, it sends a clear message: "We know better than you how you should work." This dismissive attitude is detrimental to the healthy growth of the Zed ecosystem.

If our proposed solutions are deemed unsuitable, we welcome alternative suggestions as long as the focus remains on resolving the issue. Dismissing the community's efforts and input without constructive feedback is not a healthy way to interact. While we are eager to understand the maintainers' concerns, we ask that you also extend the same respect by listening to the practical challenges we face.

I apologize again if my words came across as too harsh. It wasn't my intent to be disrespectful, and I hope we can make Zed a better product.

[okaris]

+1, I commented on the PR as well.

this doesn’t feel like it needs more aggregation. it needs a decision.

either a manual refresh is in scope or it isn’t. if it is, define the constraints and move forward. if not, say it clearly.

the current loop is the frustrating part.

[okaris]

also worth noting: the current workaround (full workspace reload) isn’t cheap.

it nukes terminal state, and if you have multiple windows open it can cascade into other workspaces as well.

so this isn’t just convenience, it’s avoiding real disruption.

[auwi-nordic]

I would like to add that I think it'd be in the interest of Zed to prioritize this issue

1. I think Zed is a very good editor to work in cluster environments. The remote workspace capability is excellent and improving rapidly, and that's very useful in many of these of environments. It makes sense for Zed to aim at attracting the kind of users who are likely to want to use the editor.
2. The kind of users working in these environments will be interacting with a larger variety of operating systems and filesystems. Getting these users on board early has immense value in providing feedback to make sure Zed becomes a stable and solid text editor that can handle anything you throw at it. Getting this feedback early can be important to make sure the code isn't locked into a design that struggles with less common environments.

These arguments is why I'd suggest going a tiny step beyond what is standard in most editors: that it should be possible to refresh a specific folder, not just the whole tree. It'd do so much to make certain users feel like the editor caters to them. A significant user base with potential customers that are very interested in this kind of editor. Catering to users with huge workspaces is also something that should provide very valuable feedback to Zed to make sure it's fast and efficient.

I have to say I'm also a bit frustrated by the hesitation to add a feature which is

1. Extremely basic feature included in almost every code editor in some form. Sometimes front-and-center in the UI (VS Code refresh button)
2. A very basic necessity to be able to work at all on many systems. The current file tree implementation is arguably fundamentally broken because it relies on an assumption which fundamentally can not be guaranteed to hold.

Maybe the PRs aren't implemented perfectly. There could be things that can be tweaked, perhaps cleaned up if we find more elegant solutions. But I don't think there should be a high barrier to get the bare necessities included in some form at this stage.

[ChristopherBiscardi]

thank you for filing this @chen1plus

I hope I haven't offended anyone

I don't see any offense here. Being frustrated is completely acceptable and you've done a good job of compiling the prior art here.

One related, but not duplicate, issue is the #51340 which proposes polling as a solution and includes a reproduction on WSL and another related discussion at #26857

either a manual refresh is in scope or it isn’t. if it is, define the constraints and move forward. if not, say it clearly.

Manual refresh has a staff opinion documented as being against it. The reason being that it could tend to mask filesystem scanning issues. In that way, a manual refresh is currently not in scope unless the community can make the case for it, which would happen here.

#51340 seems to cover the cases where a polling functionality would work, so this issue would benefit from a focus on use cases where polling and the current fs watching implementation are both unsuitable.

This seems to be HPC cluster use cases and potentially shared-storage related use cases since as described above:

these environments offer no guarantee that the operating system will provide file change notifications.

However I personally am unfamiliar with HPC systems, so do not know how to create a minimal test case for this situation.

[chen1plus]

Thanks for the positive reply. Let me answer the part about the test case and reproduction.

We don't know how to reproduce, because a lot of clusters rely on closed-source FS and complex configuration. To test that kind of FS, we need some specific hardware. However, I can show you the problem occurs on some super computers.

• France Romeo at URCA
• Taiwan Forerunner 1
• Taiwan Taiwania 3

In fact, I have this problem with almost all supercomputers I have used, including private and public clusters in France, Singapore, Taiwan, and the US.

As for polling, I haven't considered it as a solution before. Intensive polling will consume resources, but sparse polling makes changes not responding in time. If you think polling better, of course we could try it.

[PRO-2684]

I can also observe situations where the Git Panel is not updated. Maybe also a button to refresh that.

[auwi-nordic]

For our case, I can say we work using a cluster of servers with a NetApp (ONTAP I think) network filesystem. NetApps documentation is open so it's possible to read up on some of the technical details there.

But the details shouldn't really matter. In general filesystems can't absolutely guarantee timely notifications. It's also possible to experience issues with local filesystems. So relying on it is fundamentally flawed.

51340 seems to cover the cases where a polling functionality would work

Yeah, polling would be a supplementary approach. It has some issues and probably hard to get right. Should it be enabled by default for everyone? Should polling interval be configurable? Should it prioritize folders that have been opened in the file explorer? Does it work well for huge workspaces? Does it consume a lot of resources?

I think optional polling should be implemented, but I don't think it's a replacement for manual refresh, at least not in the short term. Maybe some years down the line when you've sorted out every basic issue, and you have good reason to believe nobody needs manual refresh, and/or it can be provided by a plug-in, you can remove it.

The reason being that it could tend to mask filesystem scanning issues.

This argument was trivially wrong.

Why is masking filesystem scanning issues a problem? Because you don't get user bug reports, right?

But what's worse than a user manually refreshing and maybe not submitting a bug report? That the user just gives up and doesn't use Zed at all. And which users are likely to give up on Zed? The users on alternative filesystems which is exactly where you will find corner cases that you may want to fix. The users you want bug reports from will just go "this editor is missing basic features and doesn't work.. so I'll move on"

A manual refresh option can also be a useful debugging tool when trying to figure out what's going wrong. Hell, you can even connect manual refresh to telemetry, and you'd probably get WAY more data about cases where filesystem scanning doesn't work.

[basemotive]

If there is a better solution than manually refreshing the file tree to be had, that would certainly be welcomed. Until such a solution appears, I think a manual refresh of the file tree would not hurt.

Reloading the whole workspace just isn't a good solution, as some people like myself like to work on many projects at once (I typically have at least 5 workspaces opened, some local and some remote). Having to put them all back in a workable state (where the windows are maximized, at the correct file, and the terminals are in the correct working directories and/or running the right tools) is bothersome.

The problem of the file tree not refreshing is especially problematic when working with projects that have some sort of management tool for libraries, which is basically the case for most of the modern programming languages. You install something with composer, yarn/bun, cargo, maven etc, and your management files don't appear, or when they're updated the git panel doesn't even see the updates, and before you know it you've commited something that doesn't pass the tests due to missing dependencies.
I've since learned from this and do the workspace refresh, but having to do so 10 times on a day where I'm setting up a new project and am constantly adding dependencies tends to become a bit frustrating.

The file tree refresh, while not a perfect solution, would still alleviate a lot of problems here.

Ah, I'm using a plain old NFS share off a NAS. My workstation and some VMs (with slightly different environments for testing) use the same share. Unfortunately, sharing those files across those machines is essential to my workflow on some projects.

Thank you for your consideration.

[ChristopherBiscardi]

A polling backend has landed in #54481

[okaris]

Nice, but all we wanted was a simple context menu item. Funny how to poller got in so fast.

[chen1plus]

A polling backend has landed in #54481

I'll leave this discussion open for now — let's observe the effects of this change first.

[auwi-nordic]

The poller as implemented doesn't solve the issue in general

Linux/WSL: Added polling filesystem watching support in order to support file watching on file systems that do emit events through inotify, for example /mnt/c in WSL, network filesystems, and FUSE mounts. Polling should be automatically chosen over inotify when necessary, however it can be manually chosen by setting the ZED_FILE_WATCHER_MODE=poll env var

The network filesystem we're using supports fs events. You get notifications for events from changes that happened on the same machine. But if you wrote a file on a different machine, you don't get notification for that change. In our case we would like to use watcher rather than poller. The manual refresh is just for the special cases where watcher notification failed.

I'm also a bit confused why env var is the only way to manually choose the behavior. Seems like an unnecessarily difficult way to change the configuration? Should be a workspace/project setting.

[auwi-nordic]

Maybe it helps to describe the cases where notify fails. I've experience these two myself

1. Network filesystems - can work locally, but not remote. Polling may not be desirable. Watching works better most of the time, but maybe I logged into another machine to debug an issue and while I was there I copied a log file to my workspace.. I just want to be able to see that log file in my project
2. Watch limit exceeded - again, polling is not desirable, it can be a temporary issue that the user can resolve, but they may need manual refresh until it's resolved

I asked AI to list known issues with watching, and it listed those two along with some others

Summary Table

Failure Mode	inotify Fires?	Notes
Remote FS (NFS, SMB) change	❌	Local kernel never sees it
Queue overflow	⚠️	IN_Q_OVERFLOW signals data loss
New subdir before watch added	❌	Race condition
Watch limit exceeded	❌	Silent unless you check errors
Hard link via unwatched path	❌/⚠️	Inode event fires, wrong path
Atomic rename-over	⚠️	IN_MOVED_TO not IN_MODIFY
mmap writes (unflushed)	❌/⚠️	Delayed or missing
Virtual FS (/proc, /sys)	❌	Kernel-internal writes invisible
Mount over watched path	❌	Watch is for old FS

I can't reiterate enough: without this feature the editor is fundamentally broken. I can kinda see wanting to avoid it in the beta stage. It can help motivate making sure manual refresh is needed as little as possible during this testing phase where the most serious issues should be worked out. But it should be a hard requirement for 1.0.

I would really like to recommend this editor to the other 500+ engineers in my company - and perhaps recommend an enterprise license - the moment it hits 1.0. But without manual refresh, I simply can't.

[nilsholle]

I would also like to second this. Same problems, both on HPC and also via SSH connections. Both the project and git view are often not updated. I need to switch back to VS Code for many tasks because this doesn't work without manual refresh.
In my opinion, a manual refresh button as in VS Code is the cleanest solution for these cases. Maybe many people won't need it and that's fine, but for the few cases where it is needed it is simple and it just works.

[yukiumi13]

Similar issues have come up. I’m working on a cluster where files generated by program/agents on compute nodes do exist on the login node, but they don’t show up inside Zed. In general, we monitor training from the login node, so this becomes a significant barrier to remote development.

This is why a manual refresh feature feels essential. In cluster environments, files may be created or updated by compute nodes while the editor is connected through the login node. If Zed does not reliably detect these changes, it becomes difficult to inspect logs, checkpoints, outputs, or other training artifacts during development.

Although Zed has said that remote development and agents are one of its main focuses now, this kind of file refresh issue is still a major workflow blocker for cluster users.

[chen1plus]

My apologies! I thought the polling backend was added in 1.0, but it actually came in 1.1. If you guys didn't notice this either, maybe we can just give it another shot first. I updated it and it seems to work now, though I did notice some obvious lag.

[TranToan2910]

I'm on 1.6.3 and have the same issue. I'm using WSL to run agents on my project and Zed from Windows host to view the files. Zed doesn't seem to pick up the files created by the agent. Any suggestions on how to work around this issue?

Edit: My bad, newbie mistake. Zed has the open remote folder feature that supports WSL. It works well now

[jedrichards]

I'm on 1.7.2 and I feel like something recently regressed. Neither my git panel or file tree respond to any changes I'm making in Codex.app on the mac. It needs a full restart of Zed.

To be honest, I didn't have a lot of problems around this before.

[linkthai]

I have the same problem but with Codex CLI in Zed Thread, I have to click other file and click back to see changes and sometimes I have to restart, this is very annoying because we don't even have a simple reload button in Zed.

[ekkolyth]

I'm not even working outside of the app. Making changes with Zed's own ACP integration in a local monorepo also does the same thing. Breaks git ui and stops updating the file tree.

It's been a problem for a few months (for me, at least) and the last few days it got much, much worse.

[ekkolyth]

Please. This is getting worse now. I feel like every time I use an ai agent or make changes in a different package/app of my monorepo than the one i've been actively working in, I have to restart Zed. I've been coding since 9am, it's 1:44pm, and I've had to close and reopen Zed no less than 5 times today to fix this problem. I cannot seem to find another way to actually get Zed to refresh once it breaks. I've also noticed it's not just the file tree that goes, but the entire git integration stops updating as well. I didn't realize it had happened the other day and I spent almost an hour working on the wrong branch.

It was bad before, the last few days it's regressed hard. I've been searching for a way to refresh the file tree, and then stumble on this ticket. Truly unfortunate. I really don't want to have to switch IDEs but this is now getting really frustrating.

Zed already has so many UI features/toggles/buttons. Why is it so much to ask for a refresh icon that can be hidden in config until the team finds a better long term solution?

[linkthai]

If you have tsgo installed, remove it and see if it's still buggy, I heard they found the bug and plan to push it out on an update.

[ekkolyth]

If you have tsgo installed, remove it and see if it's still buggy, I heard they found the bug and plan to push it out on an update.

i do have it in installed, for sure, but i'm almost positive it's not active right now. i'll double check and make sure, appreciate the heads up!

[linkthai]

you need to uninstall it.

[EyMaddis]

I work within a Linux Dev container (within colima instead of docker, if that matters) on my M3 MacBook (MacOS 26.5) and the issue happens regularly if I switch git branches from the outside of the container (in that folder). There were other situations were this also happened, but this seems to be a consistent pain.

I effectively need to restart the editor fully after changing branches.

One could argue I should work within Zed with git integration but that way my credentials are hidden from the container and I can use Git GUIs on my Mac. VSCode did provide such a button to refresh

[nitedani]

I am trying to switch from VS Code to Zed but I keep finding basic stuff broken.

The file explorer is completely broken for me - Windows 11 + WSL

1. The agent does some edits - it does not show up in the git chanes panel.
2. I open the file - it opens the version BEFORE the changes were made.
3. No way to make the actual filesystem and git status be in sync with what Zed shows.

[Danvil]

I have the same problem and it has become worse in the last weeks. If this continues I am going back to Sublime.

[roachadam]

sam issue for me..

[xiaozhangup]

In many cases, changes to the file system are not reflected in Zed immediately. It takes several dozen seconds for the changes to become visible.
This is extremely confusing and troublesome during development.

[smocer]

I’m seeing this with a project folder entry that is a symlink to a real directory.

If I open the symlinked folder in Zed’s file tree, files that already existed when the folder was first expanded are shown correctly. But if another process later creates new files or subdirectories inside the symlink target, Zed’s file tree does not update to show them.

If I open the real target directory directly instead of going through the symlink, the newly created files appear as expected.

So it looks like the initial directory scan follows the symlink, but later filesystem watcher events are not reflected back through the symlink path. Since there does not seem to be a manual “refresh file tree” action, the only workaround is reopening/reloading or navigating to the real target path.

[g4borg]

I had this on macos, i fixed it by adding the folder to the workspace as multifolder, avoiding following the symlink when browsing files from the editor, but keeping the symlink for the scripts. Not perfect, but until this issue hit me also with regular filesystems as well, I could live with the limitation.

[jedrichards]

Just chiming in here anecdotally, that I feel like the situation has improved. In my case, edits from Codex desktop on macOS are now appearing consistently in Zed and its file tree. Not noticing any weirdness. I'm on

Zed Preview 1.10.0 
Commit: 8d56867088a4d4269bed518cdb1f913a037179de
Version: 1.10.0+preview.315.8d56867088a4d4269bed518cdb1f913a037179de

I do not have the tsgo extension installed.

[nathanchenseanwalter]

Why has this not been fixed yet?

[Danvil]

Why is the issue closed? This is not fixed

At the very least provide "Refresh" as a right click menu item until whatever final solution is mature enough.

[g4borg]

I was just about to open an issue for this, as there are many partial fixes, and I encounter this issue almost daily on windows, and its not repairing itself. The only thing I can do is reload the entire workspace, which kills everything, when all I want is that zed should show the files that exist, and not stall due to upstream library issues.

Nobody would be hurt by a command like "workspace: filesystem refresh", if we are too proud to have a refresh entry in the right click folder menu (Of course, that would be way more efficient if you know where the file desynced)

[scilari]

Why is this closed? The issue is definitely not fixed, so this should be re-opened.

I just ran into this issue when running agentic workflows on a remote VM. The file tree refused to automatically refresh the changes, and to my surprise there was no manual option either. The file tree remained stale for at least 20 minutes, and I could not use it to access the files the agent just created.

If Zed is marketed as an editor with AI/agentic support, the suggested workflow can't be re-loading the whole workspace (or even Zed) with every agentic edit to see your files. Right click solution might not be perfect, but it would be definitely beat the current state.

[twinkle311]

Please reopen it

[Saucy9607]

The hubris in refusing to acknowledge the need for this is painful. The issue has been brought up so many times (and solved at least once!).

I encounter file watching issues on native linux and local btrfs filesystem constantly when using devenv. I guess all the symlinking from nix causes a problem.

There are always edge cases and filesystem polling is a gross hack that I'll have no part of. It causes excessive power usage and resource consumption, and sometimes other problems.

A manual refresh is needed.