computerd: writes applied over sync do not reach inotify watchers on the FUSE mount

[pltoledo]

Describe the bug

When the host pushes a change to computerd, the entry is applied straight into the in-container VFS. Reads through the FUSE mount return the new bytes, but the kernel never sees an operation on the path, so no inotify event is emitted. File watchers inside the container (Vite/chokidar, astro dev, tsc --watch, node --watch) never notice the change.

The workflow this breaks: an agent edits files through workspace.fs (or the worker-shell backend) while a dev server runs in the container. Hot module replacement never fires, and new files are not picked up by the dev server's router until it restarts.

Writes made inside the container through the mount do emit events, because they go through the kernel.

Expected behavior

A change applied by the sync push handler is visible to inotify watchers on the mount, the same way a local write is, without syncing anything back to the host.

Steps to reproduce

computerd built from main (2f76387), FUSE_MOUNT=fuse, MOUNT_POINT=/workspace. The host side is driven by pushOnce, pullOnce and reconcileWatermarks from @cloudflare/computer-rpc/driver on a SQLiteTestStorage database, as in script/computerd-soak.mjs.

1. Run inotifywait -m -r /workspace, then write a file on the host and pushOnce. The file content is correct on the mount and no event is printed. A local echo hi > /workspace/x prints CREATE, MODIFY and CLOSE_WRITE.
2. Run astro dev (Astro 7, Vite 8, chokidar 4) on a project in the mount, with an HMR WebSocket client connected. Push an edit to src/site.ts: no HMR message arrives and the page keeps serving the old content.
3. Push a new src/pages/nova.astro: GET /nova returns 404.

Environment

• @cloudflare/computer 0.4.0, computerd from main at 2f76387
• Linux x86_64 (kernel 6.18), Node 22, libfuse 2.9.9, real FUSE (/dev/fuse)
• Host side run locally with the sync driver; not yet reproduced on Cloudflare Containers

Proposed fix

Pass the applied paths to the existing afterApply hook, and in the real FUSE backend set the times of each applied path and its parent directory through the mount after the batch commits:

• ServerOptions.afterApply becomes (applied: { readonly paths: readonly string[] }) => void | Promise<void>. The shim's afterApply ignores the argument, so existing callers keep compiling.
• computerd registers afterApply: ({ paths }) => announceAppliedPaths(paths) when FUSE is mounted. utimes on the file covers edits; utimes on the parent covers creates and deletes. ENOENT is ignored.
• The FUSE utimens handler only records times in driver metadata, so the poke does not produce a VFS change and nothing syncs back.

The patch is about 30 lines in packages/rpc/src/server.ts and packages/computerd/src/cli/computerd.ts. I can share it as a diff or open a pull request if a maintainer asks for one.

Results with the patch

Case	Without patch	With patch
Pushed edit to an imported module	no HMR, stale page	full-reload 25 ms after the push, page updated
Pushed new page	/nova returns 404	/nova returns 200
Pull after the poke	0 entries	0 entries (no echo)

tsc --noEmit for packages/rpc and packages/computerd reports the same pre-existing errors in test files before and after the change.

Compatibility and open questions

• The hook signature change is additive for implementers of afterApply.
• Large batches: touching every applied path may be worth bounding, for example to the parent directories once a batch passes some size.
• The touch sets the times to now. Using the VFS mtime instead would keep stat consistent with what the host wrote.
• A privileged Docker test in the style of src/exec/runner.fuse.test.ts could run inotifywait and assert an event after a push.