Pimp My IDE / Garage Dispatch
Back to garage
September 14, 2026 · editors / filesystems / diagnostics

Your file watcher needs a dashboard.

When the project tree goes stale, “restart the editor” is not diagnosis. Watch roots, raw events, exclusions, dropped signals, and descriptor pressure belong on an inspectable surface—not buried behind vibes.

The take: a filesystem watcher is a cache-invalidation system attached to an unreliable event stream. Give it bounded memory, exportable evidence, explicit blind spots, and a rebuild path. Raising limits can buy headroom; observability tells you why the room filled.
Open the load bay

The invisible subsystem finally gets gauges.

Zed’s 1.20.1 preview adds dev: Debug Filesystem Watching. The window captures native and polling notifications before filtering and coalescing; separates raw events, watch roots, and scan exclusions; records lost-sync markers and registration errors; and exports a JSON capture with dropped-event counts plus editor and OS versions.[1]

The implementation is unusually honest about scope. It records only while the window is open, retains the latest 10,000 events, periodically compacts its editor buffers, and does not yet trace remote filesystems or worktree scan completion.[2] That is not a universal black box. It is a bounded flight recorder.

“Restart it” clears the smoke. A capture tells you which wire burned.

Capacity and causality are different repairs.

The same Zed preview raises the soft open-file limit early at startup on Unix and macOS. Its pull request says active workspaces with language servers, context servers, filesystem watchers, and agent tool calls can sit near the low GUI-inherited macOS limit before bursts push the process into EMFILE.[3]

That is sensible headroom, not absolution. More descriptors can stop a premature failure. They do not explain duplicate watches, rescan storms, exclusions that do not mean event suppression, or an event queue that lost sync. Capacity keeps the engine running; diagnostics keep you from tuning by superstition.

The operating system never promised a perfect story.

Linux’s inotify documentation says robust applications should expect monitoring races to leave a cache inconsistent and should perform consistency checks or rebuild the cache. It also notes that monitoring is not recursive, remote network events are not caught, names may be gone by the time an event is processed, and queue overflow requires recovery.[4]

Node’s fs.watch() documentation adds portable sharp edges: watching can be unreliable on network and virtualized filesystems, a deleted-and-recreated path can leave the watcher attached to the old inode on Linux and macOS, and the callback filename is not guaranteed.[5]

Build the debug surface before the next stale tree.

A useful watcher dashboard needs four planes. Raw events show what arrived. Roots show what was registered. Exclusions explain scanner policy without pretending the OS stopped emitting. Loss and recovery record overflow, dropped events, rescans, and the moment cached state became trustworthy again.

Then bind the capture to a reproduction: editor version, OS, workspace shape, local or remote filesystem, the save operation, expected state, observed stale state, and an exportable event slice. If the report cannot survive outside the reporter’s machine, it is still a ghost story.

Interactive makeover / temporal diagnostics

Watcher Load Bay.

Traditional purpose replaced: a stale-tree bug report with “it happened again.” Better version: four native capture circuits feed a temporal event tape, a deterministic save-storm drill, a coverage gauge, and a copyable evidence receipt.

Arm the capture circuits

Close only the circuits your diagnostic surface can actually export. Keyboard: Tab to move, Space to toggle. Blind runs are allowed—they expose exactly what the report would miss.

Watcher evidence circuits

OPEN / OFF = not captured  ·  CLOSED / ARMED = exportable

Drill idle.

00:00.000 BAY READY — arm circuits, then inject the deterministic drill.

Evidence coverage

0/4diagnostic planes armed

BAY BLIND: no capture planes are armed.

Open the five-source service manual
[1] Zed 1.20.1 preview release notes, September 14, 2026 — open-file-limit change and filesystem-watching debug command. [2] Zed pull request #64186 — capture planes, 10,000-event retention, compaction, JSON export, validation, and explicit diagnostic limits. [3] Zed pull request #64188 — rationale, platform targets, implementation, and tests for raising the Unix/macOS soft descriptor limit. [4] Linux inotify(7) manual — API model, queue overflow, recursion, network-filesystem limits, races, and cache-rebuild guidance. [5] Node.js filesystem documentation — fs.watch() availability, network/virtualization caveats, inode behavior, and optional filename.

Source boundary: Zed’s release and pull requests describe its own implementation and validation; they are not independent proof that every stale-tree issue is fixed. The operating-system and Node documents establish general watcher failure modes. The four-plane policy and “capacity versus causality” framing are disclosed garage opinion.