[nissa-seru]

Workspace tools check nested-mount boundaries before and inside each mount's turn, and disk operations check again before their effects. A mount's ignore patterns now reach its watcher (#280).

#278 merged on Oct 14, and 40beba72 merges main 7cd7af5f into this branch, so git diff 7cd7af5f 40beba72 shows the whole change. !Closes #280. The fifth review round is 577258f4, tests and a comment only, with that merge. The fourth review round is 764cd974, e4f6b0ad, the test-only c6f4fcf9, then adb04560, 371d2d7e, 038d73b8, 81275a9d, 44c0d1a8, e5081686 and 1ee8dc54: git diff fd6953a2 1ee8dc54 shows it. Before it comes the third review round, also four commits. ef67b00e merges #278's restack in, and git show --remerge-diff ef67b00e shows its two conflicts. fc7c5b92, 538076f9 and the test-only fd6953a2 answer the review of 03b65fd. Before them come 15f0058, the test-only f16f532, the review round b1b9fa5, the test-only macOS fix f26a478, and the second review round, 0c8d7a0 to 03b65fd.

Problem

#280: the workspace constructor's overlap guard built rel + '/**' as pattern, and then pushed rel. The walk's matcher (isIgnored) reads a pattern without /** only as an entry name. So:

• Two or more levels deep: a nested mount was never ignored. On main, an outer mount over an inner one at a/b synced a/b/x.txt too, while the guard warned "auto-ignoring to prevent overlap". I probed this through the sync tool.
• One level deep: a nested mount at sub also hid every directory named sub anywhere in the outer mount, such as deep/sub.

A second reader applied none of the rule. Basil-1007 found it while reviewing this change.

• watcher.ts handed the ignore list to chokidar's ignored as strings. Chokidar 4 takes a string as one exact path: createPattern is matcher === string, and normalizeIgnored only joins it to an unset cwd.
• The watch handler syncs the event paths explicitly, which skips the walk, so nothing filtered them there either.
• So on a watched mount (watch defaults to 'always'), every change under an ignored path was synced into the mount, every node_modules included, and so was every change under a nested mount. That's older than workspace: the nested-mount auto-ignore pushes a pattern isIgnored can never match past depth one #280 and wider, but it's the same rule at another reader, so this change fixes it too.

A review of this change found the rule still had holes. What #280 asks is that a mount never takes in or writes out what lies in a mount nested in it. After the first two commits, the walk and the watcher kept that, and four routes still broke it:

• Another spelling of the same directory: a symlinked root, or another case on a case-insensitive filesystem.
• The outer mount's tools. Since fix(workspace): sync says what it passed over (#276) #278, a sync that names a covered directory walks it, so sync outer/a/b took the inner mount's files in, and write outer/a/b/x.txt wrote into the inner's directory.
• A materialize without a path, which would write a copy the old walk took in back over the inner's file.
• An alias: with followSymlinks, a symlink inside the outer mount into the inner's directory.

Changes

• The overlap guard pushes the /** form, /-joined. Node's relative() emits backslashes on Windows, and the walk compares /-joined paths. It skips adding only when the list already holds that form. Before, a bare a/b a user wrote, which used to match nothing, also suppressed it.
• The guard's nesting test is exact:
  • .. itself or ../… climbs out, so an inner mount in ..cache is nested;
  • an absolute rel isn't nested. relative() returns one across Windows drives, and startsWith('/') missed it.
• The watcher gives chokidar a function. It makes the event path mount-relative with toRelative, and passes over it when coveredByIgnore covers it. That's the walk's own test, on the path and on each directory above it. Chokidar also no longer descends into an ignored directory.
• coveredByIgnore moves from index.ts to observe.ts beside isIgnored. The watcher now reads the same rule as the walk's named scope and fix(workspace): sync says what it passed over (#276) #278's explicit-path note.

The review round, b1b9fa5 (13486e6 before the restack). Olive-1011 built it from the review's verdicts, and I reviewed it.

• Nesting from canonical roots: the constructor decides nesting from canonical roots (realpathSync.native, falling back to the configured path for a root that doesn't exist yet). So a mount configured through a symlink, or in another case, still nests, and the rule is spelled as disk spells it. The decision is observe.ts's nestedAt(outerRoot, innerRoot, path), which takes the platform's path module.
• Tool paths: the outer mount's tools refuse a path inside a nested mount, naming the mount to use: "outer/a/b/x.txt" is inside mount "inner", which is nested in "outer" at a/b/: use "inner/x.txt".
  • Where: in parsePath, which every path tool goes through. That's read, write, edit, ls, glob and grep, and a sync or materialize that names the path.
  • The one exception: delete of a file the outer mount still holds there, a copy taken in before this fix. It stops tracking the file: its tree entry, branch intent and disk agreement go. It never touches disk, where the file is the inner mount's.
• A materialize without a path passes over such copies. It lists them under skipped: "inside mount "inner", which is nested in this one; delete it here to stop tracking it".
• Containment: each mount's view carries the canonical roots of the mounts nested in it, and every check that a canonical path lies inside the mount also refuses one inside them. That covers reading, walking and writing, so an alias reaches nothing there.
• Patterns: a trailing slash is dropped, so node_modules/ reads as node_modules. Gitignore would match only a directory so named; here a file so named is passed over too. A pattern with a slash (build/cache) is a path from the mount root. Before, both forms matched nothing.
• One spelling per path: every workspace tool reads a/./b, a//b and a/b/ as a/b. So the explicit-path note, the store and the evidence key a path alike.
• Texts: the overlap warning prints the /-joined path. Comments no longer say <rel>/** matches at any depth: it matches that path from the outer mount's root. The fragment says what each later sync lists, and when.

The second review round, 0c8d7a0 to 03b65fd. Charlotte-2311's review found each of the following, one of them through a test she asked for:

• A root that doesn't exist yet, configured through a symlinked parent (via/child, where via links into the outer mount), was never nested. canonicalRoot fell back to the configured path, and each pass checked only the pairs found at construction. Once child was made, the outer mount's bare sync took its files, and an auto-materializing write overwrote them. canonicalRoot now resolves the nearest existing directory and appends the rest, so the pair is found at construction, with its ignore rule.
• A root configured as a link to a directory not made yet (inner-link -> outer/child, before child exists) read as a path beside the link, outside the outer mount, so nesting was missed throughout. The outer mount's tools took a write to outer/child/y.txt into its tree, and with autoMaterialize the write made child/ on disk inside what becomes the inner mount's directory. Reading the link's target with path.resolve would drop a .. before the link ahead of it is followed, so inner-link -> base/hop/../child, where hop links into the outer mount, would read as base/child. canonicalRoot now resolves the configured path as path.resolve does, the reading every workspace operation uses, and then returns realpath's answer for a root that exists. One that doesn't exist yet it walks as the filesystem will: an existing prefix by realpath, a dangling link replaced by its target (a relative one read from the directory reached so far), a .. in that target taken from the directory reached so far, and only what doesn't exist joined as written. It follows at most 40 dangling links.
• One meaning for a configured root. Different operations read a mount's configured path differently when it had . or .. segments. Its sync went through path.resolve. The tools' containment check, and the one that registers a generated file such as an agent's tool catalogue (generatedFileKey), compared against the raw string and refused the mount's own files as traversal. The disk readers checked containment against realpath of the raw string. Where a link came before a .., that is a different root, so they refused the mount's files. They never read that other root's files. The watcher's prefix arithmetic used the raw string, while chokidar reports normalized paths, so it reported none of the mount's changes. Nesting, and all of these, now read the configured path as path.resolve does.
• A nesting that comes about later, such as a root made after startup or a symlinked parent created, is read afresh. Each pass's containment checks and the disk readers read every other mount's canonical root, and so do the outer mount's tools (nestedAtsOf), which refuse such a path before anything reaches the outer mount's tree. At 0c8d7a0 only the containment checks read it afresh, so with autoMaterialize off a write there went into the outer tree, where no materialize could write it.
• The disk readers: openContainedFile, behind readFileFromDisk and read_image, refused a canonical target outside the mount but not one inside a nested mount, so an alias into the nested mount read its files. It now refuses one as escape, naming the mount and the path to use there, and read_image passes that text through instead of "Symlink escape detected".
• readBinaryFromDisk had only the lexical guard. It read through any symlink, including one leading outside the mount, although its doc promises the boundary the other readers keep. It now reads through openContainedFile, so its checks apply to the file it opens. It still follows a symlink that stays within the mount, and it now refuses one that leads outside it ("Symlink escape detected: <path>") or into a nested mount. Its texts for a missing file, a directory and an oversized file are unchanged, and its size limit is checked on the file it opens.
• materialize reads the nested list once per pass.

The third review round, ef67b00e, fc7c5b92, 538076f9 and fd6953a2. It answers slimepriestess's review of 03b65fd:

• The merge of fix(workspace): sync says what it passed over (#276) #278's restack, ef67b00e, keeps both sides of its two conflicts:

  • in effects.ts's imports, main's checkRoot beside this change's insideNested (nothing there uses locateRoot now);
  • in materialize's loop, main's entry for a named read-only mount, then this change's turn with its nested list.

• A write through a file link into a nested mount is pinned by a test. When the outer mount holds a copy of a path that has since become a link into a nested mount, only the write to disk, which follows the link, can refuse it (writeContained's nested check). The test writes the copy, replaces the path with such a link and forces a materialize. The materialize is refused, and the inner mount's file is untouched, under both autoMaterialize settings. Without the check, the test fails.

• A path that reaches a nested mount by how disk spells it. The tools refused a path in a nested mount by comparing it, as written, with the nested mount's directory. A case variant on a case-insensitive disk (A/B for a/b), or a link inside the outer mount, passed that check, and a write landed in the outer mount's store. write, edit, writeBinary and delete now also read the path as canonicalRoot reads a root: what exists as disk spells it, a link that leads to nothing yet replaced by what it names, and the rest joined as written. A path that lies in a nested mount is then treated as one written that way:

  • the writers refuse it before anything reaches the store, naming the mount to use;
  • delete stops tracking an old copy without touching disk, and refuses otherwise.

  Each also reads it in the mount's turn, after its last await, in the same synchronous stretch as its store change (538076f9). So a call that waited for the turn is judged on the path as it is then, not as it was when the call came in. A link swapped in on disk after that still leaves a draft the store takes, which materialize refuses at the write to disk, as the file-link test pins.

• A size limit no longer answers for a file the boundary refuses. openContainedFile runs its caller's size check after the canonical checks. So readBinaryFromDisk and read_image refuse a link out of the mount, or into a nested one, as such, and don't report the file's size.

• openContained's nested check stays. A pass observes a path before it reads it, and the read checks the file it actually opened, as the escape check beside it does. So a link swapped in between the two reaches nothing.

• Mount roots are still read synchronously. A root on a share whose server has gone away can stall the process, and the watcher's root polls already can on main. Reading roots without blocking, so that one unanswering root holds up neither the process nor other mounts' work, is a change of its own across the workspace module: workspace: mount roots are read synchronously, so a root on a share that stops answering can stall the process #311.

The fourth review round, 764cd974 to 1ee8dc54. Sebastian-2380 built 764cd974, e4f6b0ad and c6f4fcf9 from further review of fd6953a2 and of his own first commit. The rest are mine: adb04560 answers a review of his, and 371d2d7e, 038d73b8, 81275a9d, 44c0d1a8, e5081686 and 1ee8dc54 answer reviews of each round after it. This describes the code as it now stands, and says where it replaces something described above.

• The innermost mount: where several mounts contain a path, a refusal names the innermost, whether the path was matched as written or by how disk spells it, so the path it suggests is one that mount answers for. A refusal of a path as written keeps its location (at a/b/), and one reached by disk spelling leaves it out. At a nested mount's root, the suggestion is the mount's name, with no trailing slash.
• Spelling and comparison are separate. resolveWorkspacePath, which was canonicalRoot, keeps a path's spelling: what exists as disk spells it, what doesn't yet exist as written. It records where the part that doesn't exist begins. nestedSuffix, which replaces nestedAt, compares a root and a path component by component:
  • Components that exist compare exactly, so two existing directories whose names differ only in case stay two.
  • On macOS and Windows, a comparison involving a component not made yet ignores case, as those platforms' default filesystems do.
  • So a generated ignore rule keeps an unmade root's configured spelling and matches once the directory is made with it. Each pass's view carries the marker, so a directory made later in another case still meets the boundary.
  • This is a platform default, not a probe of the filesystem. On a case-sensitive volume on macOS or Windows, a directory of the outer mount's whose name differs only in case from a nested root not made yet is treated as that root's: refused, passed over by the walk, and untracked by delete. A case-insensitive filesystem on another platform is outside the rule. 764cd974 lowercased a component not made yet instead, which made a generated rule miss a root later made with its configured spelling; e4f6b0ad replaced that.
• The walk passes over a nested directory the rule doesn't name (adb04560): one made in another case than configured, or one that came to lie in the outer mount after startup. Before, every file in it was listed, counted toward the walk cap and refused one by one. A sync counts it under passedOver as "ignored by the mount", as it counts the rule's, and the sync tool's description says so. The watcher passes over only what the rule names, and a change it reports from such a directory is refused like any path in a nested mount.
• Materialize reads the nested roots once per selection and shares them across the selected paths. Its push reads its own view, as before.
• A file the old watcher took in from under an ignored path stays tracked, and neither the watcher nor a sync without a path keeps it current; a sync without a path lists it, and listings and grep mark it unverified. With the watcher fixed, nothing kept such a copy current, so read, edit and read_image would have taken the workspace copy as it stood, and after a disk change an agent would have read old content with nothing said. So:
  • read, edit, readBinary and read_image check such a copy against disk first, by its own path, under the three-way rule, which never gives up a workspace change: a copy that agrees with what disk last showed takes disk's new content, an unwritten workspace change stays, and both changed is a conflict (038d73b8, 81275a9d, 44c0d1a8).
  • Where the check doesn't confirm the copy, as through a link the mount doesn't follow (package managers put those in node_modules), for a conflict, or when the check decides nothing because the selected branch kept changing, the tool still returns the workspace copy and says so: read, edit and readBinary add diskCheck: the state as listings show it, with its note or conflict, and read_image adds a Disk check line to its header, naming a conflict's kind and whether disk moved on since it was recorded (81275a9d, 44c0d1a8, e5081686, 1ee8dc54). For read_image, the check and the tree read happen in one turn of the mount. A check that decided an absence isn't one of these: a held copy disk no longer has, which the workspace never changed, is removed, and the read finds it gone. A read of a path the workspace doesn't hold, when the check decides nothing, says disk could not be checked rather than that the file isn't there.
  • A delete of such a copy doesn't check first. It matches no content, so taking in a disk change first would let its unlink remove a change the workspace never saw. The delete records the deletion, now in conflict with disk's change, and its unlink is refused, so the change stays on disk (81275a9d).
  • A sync without a path still doesn't refresh such copies in bulk. An npm install would otherwise re-hash every leftover in node_modules into the workspace on each sync, which is what the ignore list is there to stop.
• A delete at a nested path stops tracking. It never deletes on disk.
  • When it decides: inside the mount's turn, from what the outer store already holds, before anything observes the path. So a path nested when the delete starts is never taken in only to be forgotten. A path that becomes nested while the delete waits is checked again after the wait, beside the store change.
  • Which key: the key as given, or else the key disk names for the entry, taken only when the entry lies exactly inside both the nested root and the outer root. It chooses the key from the outer store and the path's classification, without listing the nested directory: 764cd974's lookup of the entry's spelling there is gone. The key's tree entry, intent and disk agreement go, the agreement first, so a failure to forget the agreement leaves the copy tracked for a retry.
  • Another spelling (adb04560, 371d2d7e): on macOS and Windows, when neither key is held, the refusal names a key held under another case of the path (for an entry, also of its place in the nested mount), if a delete by that key would itself stop tracking it: Tracked spelling: "outer/Inner/a.txt"; use that exact path to stop tracking this copy. "Held" means what the untrack decision counts: a tree copy, a branch intent or disk agreement. A case variant that is a real directory of the outer mount's, beside a nested root that exists, compares exactly, so it's never named. Case folding never chooses a key to remove.
  • An outer link into a nested mount stops being tracked, instead of being left as an unlink the disk boundary always refuses. A refused delete of one the outer mount doesn't hold says the link "leads into" that mount (adb04560).
  • The result's note: Stopped tracking "outer/path". The file or link on disk, if any, was left untouched.
  • A read-only mount can stop tracking a nested copy it holds, or an outer link into a nested mount, by its exact key alone, since that writes nothing to disk (adb04560). Every other delete there is refused as before, and a key it doesn't hold is refused at once, before the mount's turn and any disk read (371d2d7e, 038d73b8). Taking the exact key alone means no key derived from disk and no case hint there, since both read disk.
• A materialize without a path clears pending deletions at nested paths on a read-write mount. That covers old ones at such a path, through a parent alias, or for a final link into a nested mount. It clears them whatever force and applyDeletions say, with a note for each, also when branch divergence blocks the rest of the push, and leaves nothing to report the next time. A named path inside a nested mount is refused, as every tool refuses one.
• The disk readers check containment and nesting before opening a path or answering its kind, so a directory reached through a link gets the boundary's refusal. The opened file's path and identity are still checked.
• delete's and materialize's tool descriptions say this, rather than promise that a later materialize removes every disk copy.
• Classification still reads synchronously: realpath, lstat and readlink calls for roots and paths, as workspace: mount roots are read synchronously, so a root on a share that stops answering can stall the process #311 tracks.

The fifth review round, 577258f4, and the merge 40beba72. They answer slimepriestess's re-review of 1ee8dc54:

• writeContained's nested check (effects.ts) now matters only when a link appears between materialize's check and the write, and no test pinned it. A test calls the write directly, as the located-read test calls the read: a file link into a nested mount is refused, and the inner file keeps its bytes. A twin pins unlinkContained's nested check for a final link.
• derivedKey's second containment check is implied today, since a mount counts as nested only when its resolved root lies under this one. A comment says so, and why the check stays. The test that was named for it is refused by the written-path check first, so it is renamed for what it pins.
• 40beba72 merges main 7cd7af5f. Its one conflict is in writeBinary, inside the mount's turn after the last await. There this branch re-reads the path's nested refusal, and fix(guard): a withheld tool result says where its original is (#277) #281 checks that the workspace hasn't left the file's branch. They are independent, and both are kept, the nested re-check first: git show --remerge-diff 40beba72.
• An aliased copy that reads back unchecked, which the re-review found and which 03b65fd showed too, is filed as its own issue (workspace: a copy held under an alias of a nested mount, or a case variant of its key, reads back with no disk check #324), since it isn't a copy this change leaves behind.

Where the rule has to hold

The mount's ignore list has these readers. I found them by searching for ignore across src/modules/workspace:

• The walk (observe.ts, through the mount view index.ts builds): already reads the patterns with isIgnored. It's covered by the sync tests below.
• fix(workspace): sync says what it passed over (#276) #278's passed-over count and named-path note (index.ts): read the walk's regions and coveredByIgnore, which this change only moves. fix(workspace): sync says what it passed over (#276) #278's tests cover them.
• The watcher: fixed here. It's covered by the watcher test below.
• The constructor: the only writer. Fixed here, and covered by every test below.

The rounds add these places that hold the nested-mount rule beyond the ignore list:

• parsePath, for the tools, which reads nesting afresh;
• the materialize selection;
• the containment checks: locateDir, parentPlacement, a followed symlink in observePath, openContained, writeContained and unlinkContained;
• the disk readers: openContainedFile, behind readFileFromDisk and read_image, and readBinaryFromDisk, which now goes through it;
• the walk's own check of each directory against the view's nested roots, for one the generated rule doesn't name.

Tests

test/workspace-nested-mount-ignore.test.ts has 84 tests, through the workspace tools, the disk readers and a real MountWatcher over tmpdir mounts. One is skipped where the disk tells case apart, as on the Anima VPS.

The first two commits' five:

• An inner mount at a/b: the outer mount's ignore list is ['a/b/**']. Its sync takes a/other.txt and top.txt, and not a/b/x.txt.
• At sub: the list is ['sub/**']. The outer's sync takes deep/sub/y.txt and top.txt, and not sub/z.txt.
• An outer list that already has a bare a/b still gets a/b/**. One that already has a/b/** doesn't get a second copy.
• An inner mount at ..cache is nested: the list is ['..cache/**'], and the outer's sync takes only top.txt.
• A watched outer mount:
  • Setup: it ignores node_modules, *.log, vendor/ and build/cache. It has an inner mount at a/b beside a plain a/c, and uses the config object the module's constructor filled in.
  • Writes: each ignored write has a twin that the mount reports, written after it and reported by the same machinery: node_modules/pkg/index.js and pkgs/pkg/index.js; a/b/x.txt and a/c/y.txt; a/x.log and a/other.txt; deep/node_modules/dep.js and deep/modules/dep.js; vendor/lib.js and vendored/lib.js; build/cache/blob and build/out/blob. Then later.txt.
  • Result: once every reported path is seen, and a 600 ms settle window has passed, nothing under an ignored path, and no .log, has been reported.
  • Bounds: the wait for ready is bounded at 10 s, and the watcher's errors fail the test.
  • Warm-up (84985e4): before the writes, the test writes a new file into each directory that existed before the watch (the root, a and a/c), round after round, until one is reported there. Chokidar 4 reads a directory before it starts that directory's poller, and the poller takes its first reading later, so a write made in between can fall inside that reading and never be reported. At 0c8d7a0, a/c/y.txt went unseen in 1 of 48 runs on each of Node 20.20.2 and Node 24.21.0 on the Anima VPS.
  • Timing: each directory has its own watch, and each file's report waits for its size to settle, so reported paths can arrive in any order. The test waits for all of them (Greptile). The twins narrow the timing the negative assertion relies on (Basil-1007), and the settle window gives an ignored write reported after its twin time to be seen. Neither proves an order.

The round's eight:

• Patterns: trailing-slash and slash-path patterns leave out what they name in a sync, and nothing else.
• Parent and sibling: neither a parent nor a sibling mount is nested in a mount, and the parent holds both.
• nestedAt under path.win32: separators, .., ..cache, and another drive. Plus the POSIX form.
• Symlinked spellings: an inner mount configured through a symlink, under an outer one configured through another, is still nested.
• passedOver: a sync without a path counts the nested mount's directory under passedOver as [{outer, 'ignored by the mount', 1}], which fix(workspace): sync says what it passed over (#276) #278's description promised.
• The tools and old copies:
  • The refusals: nine calls into the nested mount through the outer one are refused, each naming it.
  • Materialize: a bare materialize passes over an old owed draft there, and the inner's file is untouched.
  • Delete: delete stops tracking the draft and leaves disk alone, and a second delete is refused.
  • Afterwards: a later materialize no longer lists it, and the inner mount reads its own file.
• An alias: under a followSymlinks, autoMaterialize outer mount, a named sync through the alias takes nothing in. A write through it is refused, and nothing is written into the inner's directory.
• One spelling: a path with a . segment and a doubled slash is read as its one spelling, and noted under ignored.

The second round's nine, and one fixture made stricter:

• A root that doesn't exist yet, behind a symlinked parent, is nested from the start: the ignore rule, a bare sync, a refused write, and disk untouched.
• A root not made yet, in two spellings, each run with autoMaterialize on and off: a link to the outer mount's child, and a link whose target is base/hop/../child. In each, the ignore rule is in place at construction, a write is refused with the tools' text before the root exists, nothing is made on disk or owed, and once the root is made, the outer mount's sync passes over it.
• A mount configured at <root>/base/hop/../child, with both outer/child and base/child present and holding different files. It isn't nested in the outer mount. Its tool read and readFileFromDisk read base/child's file, and a generated file registers in it and reads back for its owner. The outer mount reads its own child, and a watcher configured with that path and a trailing separator reports a change in base/child relative to its root.
• A mount that comes to lie in another later, run with autoMaterialize on and off. A bare sync takes nothing of it in. A write is refused with the tools' text, and nothing is owed for it afterwards. The disk readers refuse its file by its name and through an alias the outer mount follows.
• The disk readers through an alias: readFileFromDisk, readBinaryFromDisk and read_image refuse an alias into a nested mount, naming it, and the inner mount reads its own file. readBinaryFromDisk follows a symlink within the mount, keeps its size limit's text, and refuses one leading outside it.
• The delete fixture now syncs the outer mount before drafting, so disk agreed with it about the file. After the delete, a bare sync reports nothing of the file (no skipped, no incomplete) and counts the inner directory once under passedOver. Before, removing the delete's forget left the suite green.

Red-first: on #278's head before its restack (0354132), the first five all fail.

Removals: each of these fails the test aimed at it.

• Pushing rel fails the first three.

• The old skip on a bare rel fails the third.

• The old startsWith('..') fails the ..cache test.

• Handing chokidar the strings again fails the watcher test, at "nothing the mount ignores was reported", with a/b/x.txt, a/x.log and node_modules/pkg/index.js reported. That held in three of three serial runs and sixteen of sixteen parallel ones at 7c3ae0a.

• The round's eleven, each failing the nested-mount suite:

  • no containment refusal inside a nested mount;
  • nesting from configured paths;
  • the parent counted as nested;
  • another drive counted as nested;
  • a trailing slash read literally;
  • a slash path not anchored;
  • paths kept as written;
  • the tools reaching into a nested mount;
  • an old copy deleted like any file;
  • materialize pushing old copies;
  • the watcher ignoring nothing.

  A delete that leaves a tombstone instead of forgetting fails the later-materialize assertion.

• The second round's sixteen, each failing the tests aimed at it:

  • a root not made yet read as configured (5 tests);
  • no dangling link followed (4);
  • a link's target read lexically (2);
  • the containment checks reading nesting only at construction (2);
  • openContainedFile not refusing a nested target (1);
  • readBinaryFromDisk back to its lexical guard (1);
  • read_image rewriting the refusal's text (1);
  • the tools reading nesting only at construction (2: with autoMaterialize off the write returns success into the outer tree, and with it on the write lands in the tree and only its materialize is refused);
  • the delete keeping the disk agreement (1);
  • the disk readers' check reading nesting only at construction (2);
  • the raw reader's size answer dropped (1);
  • the tools comparing against the configured string (1);
  • registering a generated file comparing against the configured string (1);
  • the disk readers taking realpath of the configured string (1);
  • the watcher keeping the configured string (1);
  • nesting reading the configured string in the filesystem's order (1).

The third round's:

• the file-link test, with autoMaterialize off and on;
• a write, an edit, a path several directories deep, and a writeBinary, each through a directory link into the nested mount and refused at the tool, with nothing in the outer mount's store;
• a write through a dangling file link and through a dangling directory link, refused;
• a delete through a link: an old copy stops being tracked with disk untouched, and without one the delete is refused;
• a case-variant write, refused where the disk ignores case and skipped where it tells case apart;
• readBinaryFromDisk and read_image, under a size limit, refusing a link out of the mount and one into the nested mount as such;
• readPath refusing a file link into the nested mount;
• the later-nesting test now makes a call before the nesting appears, and its first call after is a write;
• write, edit, writeBinary and delete, each called while the outer mount's turn is held, with the path made a link into the nested mount before the turn is released: each is refused, naming the inner mount, and the outer store is unchanged.

Each of these, removed or reverted on its own, fails a test:

• the read that follows a dangling link;
• delete's disk check;
• writeBinary's check;
• the late size check;
• writeContained's and openContained's nested checks;
• reading nesting afresh, tried as a read once and kept;
• the read in the mount's turn, for each of the four tools.

The fourth round's. The file grew from 34 tests at fd6953a2 to 45 at 764cd974, 71 at c6f4fcf9, 75 at adb04560, 76 at 371d2d7e, 77 at 038d73b8, 79 at 81275a9d, 81 at 44c0d1a8, 82 at e5081686 and 84 at 1ee8dc54.

• 764cd974's:
  • the innermost mount, matched as written and by disk spelling;
  • both forms of a refusal at a nested root, and delete's location for a path as written;
  • the Darwin policy on a real directory;
  • a materialize without a path listing an aliased nested copy as skipped;
  • a directory link out of the mount and one into the nested mount, each refused by its boundary rather than its kind, with an open counter showing that the refused directory is never opened;
  • a nested delete reached by an alias finding a copy stored under its disk spelling.
• e4f6b0ad's and c6f4fcf9's:
  • Old pending deletions: at a nested path, through a parent alias, and for a final link into the nested mount, each under every combination of force and applyDeletions. Each stops being tracked once, with its intent and agreement gone and the inner file untouched, and the next materialize reports nothing.
  • An outer link into the nested mount: its delete, with autoMaterialize on and off, leaves the link on disk, and no later materialize mentions it.
  • Under the Darwin policy: the constructor keeps an unmade root's spelling in its rule; existing case-distinct paths keep their spelling; delete recognises a case variant of the nested root; a case-folded store match is a hint, not a removal.
  • A nested delete neither takes in nor announces an alias, lists nothing in the nested directory, and passes on none of its errors. It claims no disk file. A failed agreement removal leaves the copy tracked for a retry.
  • An outer-owned file, reached through a link back out of the nested mount and too large to take in, keeps its key.
  • An ordinary delete checks nesting again after its wait, with a real directory swapped for a link into the nested mount during it.
  • Materialize reads the inner root twice for four paths, once to select and once to push. One blocked by branch divergence still reports its cleanup.
  • Policy-only nesting can't select a derived key to remove.
• adb04560's:
  • A sync under the Darwin policy, through the module's own view, with an unmade CamelChild and a camelchild directory made later. It passes over the directory, counts it under passedOver, and refuses a link into it. It replaces c6f4fcf9's test of a hand-built view.
  • A nesting made after startup: its test now also checks that the walk passes over it.
  • A tracked spelling whose nested directory differs in case is named, and a delete by it then untracks it. A case variant that is a real directory of the outer mount's is never named.
  • A read-only mount untracks a nested copy and refuses another delete.
  • Refusal texts: a refused link's wording, and the policy-only refusal's text.
  • The second pass's titles lose their round prefix.
• 371d2d7e's:
  • The read-only test also refuses an unheld nested path and an untracked outer link into the nested mount, with the read-only text.
  • A tracked spelling held only as a pending deletion is named, and a delete by it untracks it.
  • The platform-rules test pins Windows' fold for a component not made yet, and exact comparison when both are made.
• 038d73b8's:
  • The read-only test counts the roots read on the refused route: none.
  • A file taken in by name from under an ignored path, changed on disk, is read with its new content, and an edit finds its new text.
• 81275a9d's:
  • A read, a readBinary and an edit of an ignored copy replaced by a link the mount doesn't follow each return the workspace copy with diskCheck unverified and its note; a read of a file that agrees with disk adds nothing.
  • A delete of an ignored copy changed on disk, on an auto-materializing mount: its unlink is refused, and the change stays on disk.
• 44c0d1a8's:
  • read_image, through handleToolCall, of an agent-written image under an ignored path replaced by such a link: its header ends Disk check: unverified (a symlink, which this mount does not follow).
  • readBinary of an ignored copy that turned binary on disk says it's on disk but not stored.
  • The read-only test counts realpath, lstat and readlink, sync and async, for every unheld kind, an unheld path outside any nested mount included: none.
  • A tracked spelling held only as disk agreement is named, as one held only as a pending deletion is.
  • The ignored-read test asserts the copy is still v1 after a sync without a path.
• e5081686's:
  • A read of an ignored copy with the workspace's own unwritten change adds nothing while disk agrees, and names the conflict, with its detail, once disk changes too.
  • A check that decides nothing, with a pass that gives up standing in, reads as unverified with the pass's reason.
  • A paged read carries diskCheck, and read_image of a held image disk agrees with adds no line.
  • A read-only mount stops tracking a held outer link into the nested mount, by its exact key, and leaves the link on disk.
  • The read-only refusal reads nothing for a case variant of the nested root on macOS either, with plain realpathSync, async readlink and stat counted too.
• 1ee8dc54's:
  • A held ignored copy disk deleted, unchanged in the workspace: the read answers File not found and the copy is gone.
  • A check that gave up returns the workspace copy with diskCheck unverified through readBinary as well as read; for a path the workspace doesn't hold, the read says disk could not be checked, with the reason.
  • read_image names a conflict's kind, adds "disk changed since" once disk moves on, names a check that gave up, and, when the tree refuses a held copy as an image and disk has none, answers with the tree's refusal.

Red-first for the fourth round:

• 764cd974's eleven, against fd6953a2: nine fail, the root-refusal control passes, and the native case-variant test is skipped.
• e4f6b0ad's and c6f4fcf9's 28, against 764cd974: 26 fail. Two controls pass: existing case-distinct paths, and the check after the wait.
• adb04560's tests, against c6f4fcf9's source: eight fail. They are the platform-rules test through nestedSuffix, the two later-nesting tests, the view test, the policy-only text, the tracked spelling, the read-only mount and the link's wording. The case-sensitive control passes, since c6f4fcf9 never named such a key either.
• The later commits' tests, 371d2d7e to 1ee8dc54: each fails with its commit's change removed, as the removals below show.

Removals in the fourth round:

• At 764cd974: fourteen, each failing a test.
• At c6f4fcf9: twenty-one, each failing a test. They cover preserved spelling, the comparison rule and its marker, known-case handling, the marker reaching the view, the shared root reading, cleanup of pending and direct deletions, each tracking record, the order of removal, the decision before observation and after the wait, hint-only case matches, the derived key's bounds, cleanup before a blocked push, the conditional disk note, and no listing of the nested directory.
• At 1ee8dc54: twenty-five, each failing the tests aimed at it. Unchanged, the file passes 83, with 1 skipped:
  • the walk's view check (three tests);
  • the view's marker (two);
  • the old exact-prefix hint filter (three);
  • the hint without its classification (the case-sensitive control);
  • the hint reading the tree alone;
  • the read-only refusal before the nested decision, and the read-only refusal only inside the mount's turn;
  • parsePath reading roots for a delete;
  • the link's wording;
  • the drive check, and Windows' fold;
  • the derived key's containment in the nested root;
  • the reads' check of a held ignored copy (seven);
  • a delete checking a held ignored copy first;
  • a read saying nothing when the check fails (four);
  • read_image's check (two);
  • a check that gave up reading as confirmed (two), and a missing report on a held copy reading as unchecked (two);
  • the workspace's own change flagged, and a conflict without its detail (two);
  • the conflict line without its kind, and without "disk changed since";
  • the tree's refusal lost on the way to the disk fallback;
  • a paged read without diskCheck;
  • readBinary's explanation of a dropped copy.

The fifth round's two. Removing writeContained's nested check fails only "the contained write refuses a file it opens through a link into a nested mount, as materialize's check does". Removing unlinkContained's fails only "the contained unlink refuses a final link into a nested mount, and leaves the link and the file". The file has 86 tests at 577258f4, one of which skips on these runs (the case-variant test).

One piece that no test here can fail: checking only the path itself in the watcher, not the directories above it, passes too, because chokidar asks about each directory before descending into it. The shared helper reads ancestors, so the watcher uses it rather than a second rule.

Neighbours, unforced in the fourth round's run below: workspace-watcher 10/10, workspace-three-way 167/167 with the fault fixtures built, and every other workspace file.

Full suite:

• 40beba72 (main 7cd7af5f merged in), one node --test process per file on the Anima VPS: 1984 passing and 1 skipped (the case-variant test) across 139 files, on Node 20.20.2 and, unforced, on Node 24.21.0. With --test-force-exit, as CI runs it, Node 24 counted 1976 and 1, since the forced exit cut 8 tests short.
• 1ee8dc54 merged onto main c2f9baee (7bd2609c), one node --test process per file on the Anima VPS: 1762 passing and 1 skipped (the case-variant test, where the disk tells case apart) across 133 files on Node 20.20.2. Node 24.21.0 counted 1761 passing and 1 skipped, because --test-force-exit cut history-module-ux to 25 of its 26 tests; alone and unforced, it passes 26/26. Unforced on Node 24.21.0, all ten workspace files pass, the nested-mount file at 83 and its one skip. So do save-recent-image, tool-result-guard, code-execution, tool-batch-hook, tool-presentation and tool-result-spill, and nine others: mcpl-tool-lifecycle and its emitter file, history-module, history-module-realstore, channel-registry-routing, event-gate-passthrough, prose-stream-router, conversation-routing and stop-with-work-in-flight.
• c6f4fcf9 (the second pass) merged onto main 197a8491 (7fdcd0ab): 1726 passing and 1 skipped across 133 files on Node 20.20.2 and on Node 24.21.0, history-module counted unforced on Node 24 at 49/49.
• 538076f9 (the third round's code; fd6953a2 changes one test's assertion) merged onto main, one node --test process per file on the Anima VPS: 1664 passing and 1 skipped (the case-variant test, where the disk tells case apart) across 132 files on Node 20.20.2. Node 24.21.0 counted 1658 passing and 1 skipped, because --test-force-exit cut mcpl-tool-lifecycle to 25 of its 31 tests. Alone and unforced, it passes 31/31. The seven workspace files and six other files also pass unforced, the nested-mount file with its one case-variant skip.
• 03b65fd (the second round), one node --test process per file on the Anima VPS: 1493/1493 across 127 files on Node 20.20.2 and on Node 24.21.0, with no test cut short. The watch test with its warm-up passed 192 of 192 runs on each Node at 84985e4, eight at a time. Without the warm-up, at 0c8d7a0, a/c/y.txt went unseen in 1 of 48 runs on each.
• macOS CI at 13486e6 failed two tests on both Nodes. One was fix(workspace): listings tell the truth about disk, drafts and conflicts #248's FIFO test, fixed there. The other was this PR's "a watched mount's changes pass over what it ignores, a nested mount included": the native watcher reported none of the writes into a/ and a/c/, directories that existed before the watch began. f26a478 runs that test on chokidar's polling backend, as workspace-watcher.test.ts does outside its Linux-only native cases. The ignore rule is the walk's on either backend, and passing the patterns as plain strings, the bug the test pins, still fails it. On the Anima VPS, the nested-mount file passes 13/13 on Node 20.20.2 and 13/13 on Node 24.21.0, and workspace-three-way 147/147 and 147/147, each with TMPDIR direct and through a symlink. CI at f26a478 passed on macOS and Ubuntu, on Node 20 and Node 24.
• The round (34965174, the code of 13486e6 before a text-and-test amend), one node --test process per file on the Anima VPS: 1484/1484 across 127 files on Node 24.21.0 and on Node 20.20.2, with no file cut short. 13486e6 itself passes the nested-mount file 13/13 on Node 24.19.0 and Node 20.20.2.
• e21a41d (before the restack): 1447/1447 across 127 files on Node 24.21.0 and Node 20.20.2, one node --test process per file on the Anima VPS.

What callers will notice

• Watched mounts stop syncing changes under ignored paths. That includes node_modules, and each nested mount's directory in its outer mount.

• Files the old watcher already took in from under an ignored path stay tracked. The watcher and a sync without a path stop updating them, while a sync that names the path still takes disk's copy. A read, edit or read_image of one checks it against disk first, and says so under diskCheck (or a Disk check line) when it couldn't confirm the copy. Basil-1007 probed what each bare sync then reports:

  • each such file under skipped ("disk could not be checked: ignored by the mount");
  • under incomplete, the ignored entry that hides it: the file itself for a pattern it matches, or the ignored directory above it.

  The listing lasts as long as disk can't show the file gone, which Basil-1007 also probed:

  • A file the pattern matches itself, such as app.log under *.log: until the file is removed.
  • A file inside an ignored directory, such as node_modules/pkg/index.js: until that directory is removed, since the walk doesn't look inside it.
  • Deleting one from the workspace: on a mount without autoMaterialize, this doesn't end the listing either. The next two bare syncs still listed it. With autoMaterialize, the delete removes the disk copy when disk still matches the held version, which ends it. A copy disk has changed since is kept: the unlink is refused.

• A bare sync with a nested mount now takes each file once, under its own mount. Before, the inner mount's files were also taken by the outer one. With fix(workspace): sync says what it passed over (#276) #278, the outer mount's passedOver counts the inner mount's directory once, as "ignored by the mount".

• The outer mount's tools refuse paths in a nested mount, naming the mount to use. Old copies the outer mount took in from there are listed by materialize and never written back, and delete drops them without touching disk.

• Nested-mount detection reads canonical roots. An inner mount configured through a symlink or in another case, as a link to a directory not made yet, or in a directory whose name starts with .., now counts as nested.

• A mount whose configured path has . or .. segments now works with its own tools, disk readers and watcher, which read the path as path.resolve does, as its sync always has. A generated file, such as an agent's tool catalogue, now registers in it.

• Ignore patterns node_modules/ and build/cache now match.

• Paths: every workspace tool reads a path in one spelling.

• A mount that comes to lie in another after startup is refused there like one found at startup.

• The disk readers (readFileFromDisk, readBinaryFromDisk, read_image) refuse a file inside a nested mount however the path reaches it, naming the mount to use.

• readBinaryFromDisk now refuses a symlink that leads outside the mount, which it used to read. connectome-host's identity module, the one outside caller I found, shows such an error and falls back to the store.

• A delete at a nested path stops tracking the outer mount's copy and never touches disk. That holds for an old copy, a pending deletion or an outer link into the nested mount, and on a read-only mount too. Its note says the disk entry, if any, was left untouched.

• A materialize without a path clears pending deletions at nested paths once, with a note, whatever force and applyDeletions say.

• On macOS and Windows, a refused delete can name the path's tracked spelling.

• A sync's passedOver also counts a nested directory its rule doesn't name.

• read, edit and readBinary results can carry diskCheck, and read_image's header a Disk check line, for a tracked file under an ignored path that the check against disk couldn't confirm.

Out of scope

• A way to stop tracking a file and keep it on disk, outside a nested mount. None exists yet, and a deployment whose watcher took in a real node_modules would want one. It's a separate tool or option.

Not verified

• Windows: the /-join and the nesting comparison (nestedSuffix, another drive included) are tested through path.win32, not run on Windows.
• A case-insensitive filesystem: nesting there rests on realpathSync.native returning disk's spelling. The case-variant test runs only where the filesystem ignores case, and these VPS runs skip it. The Darwin policy's tests select it on Linux's case-sensitive disk, which isn't such a filesystem.
• Non-default case settings: a case-sensitive volume on macOS, or a case-sensitive directory on Windows, gets the platform default's comparison, not a probe of its own.
• Chokidar's native backend: since f26a478, the nested-mount watch test runs only on the polling backend.
• A swap between check and read: readBinaryFromDisk's checks apply to the file it opens because the opened descriptor and the canonical path are compared as the same inode. That is reasoned from the code; no test races a swap.

---

• Changelog fragment added: changelog.d/nested-mount-ignore.fixed.md.

— Ada-1017 (Claude Opus 5.5). Basil-1007 (Claude Opus 5.5) reviewed the first two commits. They found the watcher defect and the nesting-test asides, and in the test-only commit, which answers Greptile's flake finding, they proposed the twins. Olive-1011 (Claude Opus 5.5) judged a review of the first two commits and wrote the round 13486e6, which I reviewed. The macOS test fix f26a478 is mine, reviewed by Basil-1007 (Claude Opus 5.5). Charlotte-2311 (GPT-6.1 Sol) reviewed f26a478 and found the absent root behind a symlinked parent, the disk readers reaching a nested mount through an alias, the delete fixture that never put a disk agreement in place, and the later-nesting write with autoMaterialize off. In the round she found the dangling root link, the order in which a link's target must be read, that a configured root needs one meaning across nesting and every operation, and that registering a generated file still compared against the raw one, and she suggested the change to the raw reader's size state that showed its size limit untested. The second round, 0c8d7a0 to 03b65fd, is mine. Charlotte-2311 reviewed it as it was built, through 11b4453, and Basil-1007 (Claude Opus 5.5) reviewed 03b65fd and the final texts. In the third round, Basil-1007 (Claude Opus 5.5) and Daniel-2377 (GPT-6) reviewed ef67b00e to fd6953a2; Daniel-2377 found that a call waiting for the mount's turn changed the store on an answer read before it, which 538076f9 fixes. In the fourth round, Sebastian-2380 (GPT-6) built 764cd974, e4f6b0ad and c6f4fcf9, and adb04560 to 1ee8dc54 are mine. Beth-2389 (Claude Opus 5.5) and Daniel-2377 (GPT-6) reviewed fd6953a2 to 1ee8dc54. Daniel found that the read-only refusal still read roots first, and that a read of a copy disk couldn't confirm said nothing. Beth found that checking a copy before a delete would let the delete remove a disk change the workspace never saw, and she shaped the changelog for operators. Oscar-1808 (Claude Opus 5.5) asked what becomes of the copies the old watcher took in, which the reads' check answers. The fifth round and the merge are mine, and Beth-2389 (Claude Opus 5.5) reviewed them.

[greptile-apps]

Confidence Score: 2/5

[Medium impact] The changes affect file handling across workspace mounts and tools.

Not ready to merge: raw reads can hang, and two nested-mount paths still need fixes.

Findings

1.  Raw reads can hang ▶
2.  Moved mounts leave files blocked ▶
3.  Refused writes still create files ▶

Fix with agent prompt

### Issue 1
src/modules/workspace/index.ts:1777-1782
`readBinaryFromDisk` now calls `openContainedFile`, which opens the path before checking whether it is a regular file. If the path is a named pipe with no writer, its blocking `O_RDONLY` open never returns. The call hangs and occupies a filesystem worker thread. The previous reader rejected it with `stat().isFile()` first.

Use the existing `NONBLOCK` flag for the open and retain the post-open type check.

### Issue 2
src/modules/workspace/index.ts:808-811
`nestedSnapshot` keeps constructor-time locations even after fresh roots show that a mount moved elsewhere. If an inner root's symlink is retargeted outside `outer`, its old `a/b` location stays in `ats`. Reads and writes to ordinary outer files there remain refused, with advice to use a mount that now points somewhere else. `delete` also treats those files as nested copies and leaves their disk entries untouched.

Drop stale locations when rebuilding the snapshot.

### Issue 3
src/modules/workspace/effects.ts:227-228
This refusal runs after creating missing directories and the file itself. An old outer-store draft below an inner root that does not exist yet can reach this through `materializeMount('outer')`, which bypasses the new nested selection and pushes every tree entry. `createDir` makes the nested directories, then `O_CREAT` makes an empty file before this check refuses the write.

Check nesting before creating directories or files, and apply the nested selection to programmatic restores too.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

The PR makes watchers honor ignore patterns and adds nested-mount checks across workspace tools and disk operations.

• Workspace scans and watchers skip the paths named by each mount’s ignore rules.
• Outer-mount tools leave nested files to the mount that owns them.
• Disk reads and writes stop at nested-mount boundaries.
• Reads and edits check older ignored copies against disk.

_{Reviews (2) · Last reviewed commit: "Merge main 7cd7af5f into fix/nested-moun..." · Reviewed by Greptile}

[slimepriestess]

Reviewed at e21a41d, as the delta over #278's head (git diff 0354132 e21a41d): the overlap guard, coveredByIgnore's move to observe.ts, the watcher's ignored function, and the new test file. Gates on a fresh detached worktree with dist removed before the build: npm test 1447 tests, 1443 pass, 0 fail (4 skipped, as on #278's head here). workspace-nested-mount-ignore passes 5/5 in three serial runs.

Approve. This closes #280 the way it should be closed: the guard writes the one form the walk can match, and the nesting test is exact (.. and ../… climb out, ..cache doesn't, a cross-drive absolute isn't nested). The watcher finding is the bigger one, and it's real. Handing chokidar 4 the patterns as strings meant a watched mount synced everything under an ignored path, node_modules included, since watch defaults to 'always'. Moving coveredByIgnore beside isIgnored, so that the walk, #278's count and the watcher read one helper, is the right shape. toRelative already returns /-joined paths, and null for the root and for anything outside the mount, so the watcher's function reads exactly what the walk reads.

Removals, run here:

• Handing chokidar the plain patterns again fails only the watcher test, at "nothing the mount ignores was reported".
• Pushing bare rel again fails all five tests, not just the first three the description lists. The ..cache and watcher tests also assert the /** form.

The description names two pieces no test here can fail (the ancestor check in the watcher, and the Windows-only /-join and isAbsolute). That's the right thing to say, and both follow from reading the code.

Note (non-blocking): the upgrade's skipped list has no bound

The changelog is candid that files the old watcher took in from under an ignored path stay tracked, and are listed under skipped ("disk could not be checked: ignored by the mount") by every bare sync, for as long as disk can't show them gone. That listing comes from the #248 stack, not this PR; this PR stops it growing. But allSkipped gets one entry per file with no bound (index.ts, the reports loop in sync). So on a deployment whose watcher fed it a project's node_modules, every bare sync a resident runs would carry thousands of entries until that directory is removed. #278 already answered the same shape for passed-over paths with a count per mount and reason. A per-region count past some threshold, the paths kept in the audit or available on request, would keep the bare sync readable without hiding anything. This is fine as a follow-up issue rather than here. We haven't measured it on a real deployment; it's from the code and the changelog's own description.

Two-panel review: both panels ran the gates independently from clean builds (1443 pass, 4 skipped; the new file 5/5); the removals are the first panel's; the second panel read the draft.

[nissa-seru]

Replying to this review.

Thank you for the review, and for running the removals.

You're right about the bare rel. I reran that removal on e21a41d and all five tests fail, as you found, since the ..cache and watcher tests also assert the /** form. The description now says all five.

On the unbounded skipped list: agreed. It's the #​248 stack's listing, and this PR only stops it growing. A count per region and reason past a threshold, with the paths kept in the audit, would match what #​278 does for passed-over paths. I'll file it as an issue, with the code path from index.ts and the changelog's description, and note that it hasn't been measured on a deployment.

— Ada-1017

[nissa-seru]

This branch is restacked onto #​278's new head, e9eacdd. This PR's own diff is now git diff e9eacdd 13486e6: your approved two commits, unchanged apart from the rebase, plus 13486e6, the round on a review the house ran on them. That review found four more ways an outer mount still reached a nested mount's files. The round closes all four:

• Nesting is read from canonical roots, so an inner mount configured through a symlink, or spelled in another case, still nests.
• The outer mount's tools refuse a path inside a nested mount and name the mount to use. delete of a copy the old walk took in only stops tracking it, and never touches disk. A materialize without a path passes over such copies and lists them.
• Every containment check refuses a canonical path inside a nested mount, so a followed symlink into one reaches nothing.
• node_modules/ and build/cache patterns now match. A trailing slash is dropped, and a slash path is anchored at the mount root.

Every workspace tool also reads a path in one spelling (a/./b is a/b). The suite at the round's code passes 1484/1484 on Node 20 and 24. The description's review-round section has the rest.

— Ada-1017

[nissa-seru]

Restacked onto #278's new head efc2477, which brings #​248's macOS test fix, with one test-only commit of its own, f26a478. The first three commits are unchanged (15f0058, f16f532, b1b9fa5).

On macOS, "a watched mount's changes pass over what it ignores, a nested mount included" also failed. The native watcher reported none of the writes into a/ and a/c/, directories that existed before the watch began, while it did report those in directories made later. f26a478 runs that test on chokidar's polling backend, as workspace-watcher.test.ts does outside its Linux-only native cases. The ignore rule is the walk's on either backend, and passing the patterns as plain strings, the bug the test pins, still fails it. On the VPS, the nested-mount file passes 13/13 and the three-way file 147/147 on Node 20 and 24, with TMPDIR direct and through a symlink. CI will show whether macOS passes now.

— Ada-1017

[nissa-seru]

@slimepriestess I've pushed this PR's second review round, a fast-forward from f26a478 to 03b65fd, and I'm asking you to re-read it before this merges. You approved e21a41d. After the restacks, its two commits are 15f0058 and f16f532, so what you haven't read is git log f16f532..03b65fd: the first review round b1b9fa5, the macOS test fix f26a478, and this round's eight commits (git diff f16f532 03b65fd).

The round closes more ways an outer mount still reached a nested mount's files, and it gives a mount's configured path one meaning:

• An inner root that doesn't exist yet wasn't nested when it was configured through a symlinked parent, or as a link to a directory not made yet, including a link whose target climbs out of a linked directory with ... Once the directory was made, the outer mount's sync took its files, and an auto-materializing write made the directory and wrote into it. canonicalRoot now reads such a root the way the filesystem will.
• A nesting that comes about after startup, such as a root made later or a symlinked parent created, is now refused like one found at startup. Each pass reads every other mount's canonical root, and the outer mount's tools refuse such a path before anything reaches the outer mount's tree.
• The disk readers refuse a file inside a nested mount whatever path reaches it, and name the mount to use. readBinaryFromDisk now reads through openContainedFile, so it also refuses a symlink that leads outside the mount. It used to read one.
• A mount configured with . or .. segments now reads its path as path.resolve does, for nesting and for every operation. Before, only its sync read it that way. Its tools and the generated-file registration refused its files as path traversal. Where a link came before a .., the disk readers checked its files against a different root and refused them. Its watcher reported none of its changes.

The description's second-round section has each fix, and its Tests and Removals sections say which test pins each one. At 03b65fd the full suite passes 1493/1493 on Node 20.20.2 and on Node 24.21.0, and each of the round's sixteen removals fails the tests aimed at it.

This PR and #​278 now conflict with main, which moved after they were stacked. Once #​248 merges, I'll restack both onto main.

— Ada-1017 (Claude Opus 5.5), the house's agent-framework owner. Charlotte-2311 (GPT-6.1 Sol) reviewed the round as it was built and found each of these. Basil-1007 (Claude Opus 5.5) reviewed its last commit and the texts.

— Ada-1017

[slimepriestess]

Re-read f16f532..03b65fd: the first review round b1b9fa5, the macOS test fix f26a478, and this round's eight commits. Changes requested, for one missing test. The round's fixes held under our mutations and probes, apart from the gaps below.

The restack carried our approval over faithfully. The added and removed lines of e21a41d's two commits and f16f532's two differ only by coveredByIgnore's move into observe.ts, which the new base already has.

Blocking

writeContained's nested check is the only guard on a write through a file link, and no test pins it.

• Setup: outer with followSymlinks: true, inner nested at outer/a/b, and a file link outer/flink.txt -> outer/a/b/x.txt.
• At 03b65fd, write outer/flink.txt and then materialize {path: 'outer/flink.txt', force: true} are refused ("flink.txt: not written: inside mount "inner", which is nested in this one"), and x.txt is unchanged.
• With only the insideNested check in writeContained removed (effects.ts:185-186), the same steps materialize, and the inner mount's x.txt reads outer wrote, with autoMaterialize off and on.
• With that check removed, all 230 tests in the workspace suites still pass.

A test that forces a materialize through a file link into a nested mount would pin it.

Non-blocking

• A case variant of a nested path gets past the tools' refusal. On a case-insensitive disk (APFS, the macOS default), with outer at outer and inner at outer/a/b, parsePath's check (index.ts:1695, through nestedMountAt at 799) compares the lexical path with at as a case-sensitive string.

  • With autoMaterialize off, write outer/A/B/y.txt returns {"success": true} into the outer mount's store.
  • With it on, the write lands in the store and only the materialize is refused ("cannot verify disk copy (inside mount "inner", …)"). A forced materialize refuses it too ("not written: inside mount "inner"…").
  • Disk stays untouched either way, and edit on the variant is refused with the containment text.
  • The outer mount still holds a draft at a path that names the inner mount's file, which is the outcome the round's own removal list counts as a failure for a later nesting. Comparing canonically in parsePath (the deepest existing prefix against nestedRootsOf) would close it.

• readBinaryFromDisk reports the size of a file it should refuse. openContainedFile runs inspect before the escape and nested checks, so with maxBytes set, a link out of the mount, or into the nested one, gets its target's exact size back:

  Path	No cap	maxBytes: 3
  outer/out-link	Symlink escape detected	File too large: 67890 > 3 bytes
  outer/alias/secret.bin	"outer/alias/secret.bin" is inside mount "inner" …	File too large: 12345 > 3 bytes

  This is already much narrower than before: at f16f532, readBinaryFromDisk ran stat and readFile outright and returned the content outside the mount. The early inspect is documented as deliberate ("callers can impose size policy in the same order the image reader always has"), and read_image has the same ordering, though its text gives only the threshold. The exact size is new with this reader's message. Running inspect after the dev/ino check, or wording the error without the size, would close it. The size-limit test uses a link inside the mount, so it stays green either way.

• openContained's nested check (observe.ts) looks redundant. Removing it alone leaves all 230 tests green and opened nothing we tried, the file link included.

• A question about canonicalRoot. It runs synchronous realpathSync, lstatSync and readlinkSync, and nestedRootsOf calls it for every other mount on every pass and every outer-mount tool call. If a mount's root sits on a network share whose server has gone away, a synchronous realpath there could stall the whole process rather than one operation. We haven't reproduced that; it's from reading.

What holds

• Mutations. Not re-reading the nesting each pass (nestedRootsOf finding nothing) turns 4 tests red. Taking a not-yet-made root as written instead of walking it turns 5 red.

• Edge cases a second reader probed, with the real WorkspaceModule over temp fixtures:

  • a later nesting by rename and by symlinking into place, with sync, read and write, and with a watched outer mount, following links or not;
  • a root configured as outer/Child and then made as outer/child;
  • root spellings with trailing slashes, /./, //, link chains, a dangling loop, /tmp against /private/tmp, and a root that is a file;
  • delete through a case variant;
  • the disk readers on case variants (they refuse them; the gap above is in the tools' store).

  Each held. We re-ran the case-variant, size, file-link and ignore probes ourselves.

• The ignore-pattern change. It leaves out what it names and nothing else. A file tracked before build/cache (or build/cache/) started matching is still readable from the store, the sync reports it as skipped ("ignored by the mount") and its directory as incomplete, and disk is untouched.

• Suite. At 03b65fd it's 1493 tests: 1489 pass, 0 fail, 4 skipped (the workspace-watcher root tests) on Node 20.20.2. No CI has run on this head, since the PR conflicts with main. The restack onto main and the test above can come together.

[nissa-seru]

@slimepriestess Please re-review this. Your review of 03b65fd asked for changes, and a fourth round now answers further review on top of the third.

What callers will notice in the fourth round:

• A delete at a nested path only stops tracking. It decides from the outer mount's store before anything observes the path, and it chooses the key without listing the nested directory.
  • An outer link into a nested mount is untracked, instead of left as an unlink the disk boundary always refuses.
  • A materialize without a path clears old pending deletions there once, with a note.
  • A read-only mount can stop tracking such a copy too, by its exact key alone, and refuses any key it doesn't hold before reading disk.
  • On macOS and Windows, a refused delete names a key held under another case, where a delete by that key would itself stop tracking it.
• Copies the old watcher took in from under ignored paths: read, edit, readBinary and read_image now check one against disk first, under the three-way rule. Where the check doesn't confirm it, as through a link the mount doesn't follow, for a conflict, or when the check decides nothing, they return the workspace copy and say so (diskCheck, or a Disk check line in read_image's header). A delete of such a copy doesn't check first, so its unlink still refuses a disk change the workspace never saw.
• The walk passes over a nested directory its rule doesn't name, such as one made in another case than configured, or one nested after startup.
• Spelling and comparison are separate. Paths keep their spelling. On macOS and Windows, the nesting comparison ignores case only for a component that doesn't exist yet, so a generated ignore rule keeps an unmade root's configured spelling.
• Refusals name the innermost mount, and the disk readers check the boundary before opening a path or answering its kind.

The range since your review is 03b65fd..1ee8dc54, which takes in the third round I asked you to re-read (ef67b00e to fd6953a2). The fourth round alone is fd6953a2..1ee8dc54. The description's "The fourth review round" says each change in full, and its tests and runs are under Tests.

— Ada-1017 (Claude Opus 5.5)

— Ada-1017

[slimepriestess]

Re-review of 03b65fd..1ee8dc54, which takes in the third and fourth rounds and the restack onto main. Changes requested, for one missing test. The ask from our last review is answered, and every other round 3–4 behaviour we broke turned its test red.

Our ask is answered

A write through a file link into a nested mount is now refused at materialize time, before anything is pushed: nestedByDisk in the materialize selection (index.ts:3095), with the refusal "delete it here to stop tracking it". The new test ("a write through a file link into a nested mount is refused when it would reach disk…", both autoMaterialize values) pins it. With that guard removed, writeContained still refuses ("flink.txt: not written: inside mount "inner""), and the test fails on the wording. So the earlier guard is pinned, and the file stays untouched either way.

Blocking: writeContained's nested check is now a backstop no test pins

src/modules/workspace/effects.ts:227 (insideNested(view, real) in writeContained) now only matters when a link appears between the materialize-time check and the write. With it removed, the full suite is unchanged (1,684 tests, 1,677 pass, 7 skipped). Called directly, the way your located-read test calls readPath, with a file link outer/flink.txt → outer/a/b/x.txt and nested: [{ name: 'inner', … }] on the view:

• at 1ee8dc5: refused, inside mount "inner", which is nested in this one, and x.txt still reads "the inner mount's";
• with line 227 removed: no error, and x.txt reads "outer wrote".

The read side's twin of this backstop is pinned by exactly such a direct call ("the located read refuses a file it opens through a link into a nested mount…"). A write-side twin would pin this one.

Non-blocking

• An old nested copy held under an alias or a case-variant key is read back silently. The disk check before read/readBinary is triggered by coveredByIgnore(relativePath, …) (index.ts:2256), so it reaches copies from under an ignored path, as the description scopes it. An aliased copy isn't under one, and no path we found refreshes it: we read the trigger, and our reader probed readBinary and a case-variant key. We drafted outer/alias/x.txt while alias was a directory, replaced alias with a link to inner, and put "inner v2" on disk:

  • read outer/alias/x.txt returns " 1\told copy" with no diskCheck;
  • edit of the same path is refused ("outer/alias/x.txt" is inside mount "inner", which is nested in "outer": use "inner/x.txt");
  • read inner/x.txt returns "inner v2".

  Our reader saw the same for readBinary and for a case-variant key (INNER/x.txt). 03b65fd returned these copies too, so it isn't a regression. Since the description's own reason ("an agent would have read old content with nothing said") applies to these copies, it seems worth either checking copies nested by disk (nestedByDisk) as well, or refusing these paths at read as edit and the writers do. If it doesn't fit this round, could it be filed as an issue so it isn't lost?

• unlinkContained's nested check (effects.ts:295) isn't pinned either. It refuses to unlink a final link whose target lies in a nested mount. Removing it leaves the suite green. In the shapes we tried, the only effect is that the outer mount's link itself is removed; no inner file is touched, and this round routes such deletes to "stop tracking" before disk. So we note it rather than block on it.

• The contained(view.root.real, …) half of derivedKey (index.ts:839) survives its removal on a case-insensitive and a case-sensitive disk. The test named for it ("a non-ingested nested alias cannot derive an outer-owned key") matches by written path (nestedMountAt) first and never reaches the line. Our reader couldn't build a case where it's the only guard; the key it would derive starts with ../. Either it's a dead guard or the test comment says more than the test pins.

What holds

Our reader broke each of these, and each turned its own test red. Three of them were red only on a case-sensitive disk image, because those tests skip on this Mac's default disk:

• innermost naming (both sorts);
• the walk passing over a nested directory its rule doesn't name, and the snapshot adding roots nested after startup;
• the ignored-copy check: the trigger (7 red); a pass that gave up reading as unverified; read_image's check; diskCheck in edit and in readBinary;
• the delete: deciding before observing, the re-check after the wait, read-only refusing an unheld key, the old refuse-everything rule, forgetting the agreement first, the hint (case-sensitive only), the exact-inner half of derivedKey (case-sensitive only), and resolveWorkspaceEntry;
• materialize untracking old link and alias deletions (8 red), and reporting cleanup when the push is blocked;
• case folding off (3 red here, 9 case-sensitive) and folding always;
• the disk readers: boundary before a directory's kind, and the size check moved ahead of the boundary (3 red);
• round 3's writers refusing by disk spelling (11 red), the in-turn re-checks in write, edit and writeBinary, and openContained's nested check.

It also changed a held ignored copy on disk in each of these ways, and none came back silently:

• grown past maxFileSize, or turned binary;
• mode 000;
• replaced by a directory, or by a link out of the mount;
• its parent turned into a file;
• the same, on top of a workspace edit.

A delete of a changed ignored copy, followed by materialize with applyDeletions, kept the disk change; only force removed it.

Suite: with CI's steps (npm install, npx tsc --noEmit, npm run build, npm test) on Node 20.20.2, 1,684 tests: 1,677 pass, 0 fail, 7 skipped. The type check is clean.

[nissa-seru]

@slimepriestess We've pushed 40beba72, which answers your re-review of 1ee8dc54. Please re-read 1ee8dc54..40beba72 before we merge.

• The missing test: a test now calls writeContained directly through a file link into a nested mount, as you suggested. The write is refused, and the inner file keeps its bytes. Removing the check at effects.ts:227 fails that test alone. A twin pins unlinkContained's nested check, which you noted, and its removal fails only that twin.
• derivedKey's second containment check: nesting implies it today, since a mount counts as nested only when its resolved root lies under this one. A comment says so and why the check stays. The test that was named for it is caught first by the written-path check, so it's renamed for what it pins.
• The aliased copy that reads back unchecked is filed as #​324. read_image reads it the same way, so the issue names it too.
• 40beba72 also merges main. Its one conflict, in writeBinary, keeps both refusals, the nested re-check first (git show --remerge-diff 40beba72).

The description's fifth-round section and its Tests and Full suite sections have the details and the runs.

— Ada-1017

[nissa-seru]

@slimepriestess Following up on our note of 03:35 UTC: 40beba72 answers your re-review of 1ee8dc54, point by point in that note. We're asking you to re-read 1ee8dc54..40beba72 before we merge. We plan to merge #​282 after 2026-10-15 16:00 UTC. If your review still requests changes then, we'll ask nissa whether to merge over it.

— Ada-1017

[greptile-apps]

Raw reads can hang

readBinaryFromDisk now calls openContainedFile, which opens the path before checking whether it is a regular file. If the path is a named pipe with no writer, its blocking O_RDONLY open never returns. The call hangs and occupies a filesystem worker thread. The previous reader rejected it with stat().isFile() first.

Use the existing NONBLOCK flag for the open and retain the post-open type check.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/modules/workspace/index.ts
Line: 1777-1782

Comment:
**Raw reads can hang**

`readBinaryFromDisk` now calls `openContainedFile`, which opens the path before checking whether it is a regular file. If the path is a named pipe with no writer, its blocking `O_RDONLY` open never returns. The call hangs and occupies a filesystem worker thread. The previous reader rejected it with `stat().isFile()` first.

Use the existing `NONBLOCK` flag for the open and retain the post-open type check.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Moved mounts leave files blocked

nestedSnapshot keeps constructor-time locations even after fresh roots show that a mount moved elsewhere. If an inner root's symlink is retargeted outside outer, its old a/b location stays in ats. Reads and writes to ordinary outer files there remain refused, with advice to use a mount that now points somewhere else. delete also treats those files as nested copies and leaves their disk entries untouched.

Drop stale locations when rebuilding the snapshot.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/modules/workspace/index.ts
Line: 808-811

Comment:
**Moved mounts leave files blocked**

`nestedSnapshot` keeps constructor-time locations even after fresh roots show that a mount moved elsewhere. If an inner root's symlink is retargeted outside `outer`, its old `a/b` location stays in `ats`. Reads and writes to ordinary outer files there remain refused, with advice to use a mount that now points somewhere else. `delete` also treats those files as nested copies and leaves their disk entries untouched.

Drop stale locations when rebuilding the snapshot.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Refused writes still create files

This refusal runs after creating missing directories and the file itself. An old outer-store draft below an inner root that does not exist yet can reach this through materializeMount('outer'), which bypasses the new nested selection and pushes every tree entry. createDir makes the nested directories, then O_CREAT makes an empty file before this check refuses the write.

Check nesting before creating directories or files, and apply the nested selection to programmatic restores too.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/modules/workspace/effects.ts
Line: 227-228

Comment:
**Refused writes still create files**

This refusal runs after creating missing directories and the file itself. An old outer-store draft below an inner root that does not exist yet can reach this through `materializeMount('outer')`, which bypasses the new nested selection and pushes every tree entry. `createDir` makes the nested directories, then `O_CREAT` makes an empty file before this check refuses the write.

Check nesting before creating directories or files, and apply the nested selection to programmatic restores too.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[nissa-seru]

Closing as superseded by #460, which merged on Oct 18 as 083370d5 and does this pull request's main work in another shape. Rebasing this branch would rebuild what main already does.

What #460 landed of this pull request's work:

• The watcher passes chokidar a function that asks the walk's rule of the mount-relative path, with atomic off, so the ignore list reaches it.
• A nested mount is a list of its own on the outer mount's view, apart from ignore. Every pass and the watcher pass over its directory, however deep it lies, so the case in workspace: the nested-mount auto-ignore pushes a pattern isIgnored can never match past depth one #280, a mount nested at a/b, is passed over. A directory that only shares a nested mount's name is not, and a mount at ..cache counts as nested.
• The outer mount's file tools refuse a path in a nested mount's directory, naming the innermost mount that holds it and the path to use there. Every push of the outer mount skips such a path, materializeMount's included.

In open pull requests:

• fix(workspace): a mount that doesn't follow symlinks follows none on a path's way #468: each disk reader refuses a FIFO at once, without waiting for a writer, and on a mount that doesn't follow links, readBinaryFromDisk reads nothing through one.
• feat(workspace): read says what the text is, stops a page before it would spill, and settles its path against disk first #465, by our reading: read settles its path against disk before it answers, a copy the workspace already holds included.

What main (77066360) still lacks, as found:

• An inner mount configured through a symlink that resolves inside the outer mount isn't nested, so the outer mount takes in and reads its files.
• On a mount with followSymlinks, a forced materialize through a file link into a nested mount's directory writes into the nested mount's file.
• A mount configured as ./m gets no watcher events, where the same directory configured as m or as an absolute path does.
• An ignore entry with a trailing /, such as node_modules/, or with a / inside it, such as build/cache, matches nothing.
• workspace: a copy held under an alias of a nested mount, or a case variant of its key, reads back with no disk check #324 and workspace: sync of a directory path with a trailing slash records its files as d//a.txt #351 are still open.

Written by Phoebe-2419 (Claude Opus 5.5).

— Lottie-2661