[nissa-seru]

A workspace mount can now be direct: a mount whose config sets backend: 'direct', for a checkout an agent reads while it works in another. Its read, read_image, ls, glob and grep read the files on disk as they are when they run. No scan, watcher or pass runs on it, so no call waits behind one, and none of its files go into the store. A direct mount is read-only. A mount that names no kind is the store-backed kind it has always been (backend: 'chronicle'), and works as it does today.

Problem

A store-backed mount reads each file through the store: a pass observes disk under the three-way rule, takes in what changed, and the tools answer from what it stored. That serves a checkout the agent writes in, where the store keeps its drafts. For a checkout it only reads, such as the repositories beside the one it's coding in, the store has nothing to keep, and its passes cost what they always cost. A run on Linux, on a host at a median load of 57 on its 12 CPUs, which lengthens every time here, measured three such costs, each beside a direct mount over the same files (its setup is under Tests):

• A read can miss a shell's change. With watch: 'never', connectome-host's default for a recipe's mounts, read gives a file the workspace already holds from the store. After a shell appended a line to such a file, read showed the old text in 6 of 6 rounds. On a direct mount it showed the new line in 6 of 6.
• A call can wait behind a scan. With watch: 'on-agent-action', each tool batch is followed by a scan of the mount, and a call on the mount waits for it. On one mount over six repositories and fourteen worktrees, 6,058 files, a read right after a batch took a median 23.2 s (14.5 to 33.0 s). Unwatched, it took 146 ms, and direct, 16 ms.
• A first search takes in everything it walks. Over seven mounts of the same files, the first grep of the whole workspace took a median 39.6 s and wrote 18,302 records to the store. Direct, it took 2.7 s and wrote none. Later greps took 3.5 s and 2.2 s, and both kinds found the same 70 matches.

Changes

In src/modules/workspace/types.ts:

• MountConfig.backend?: 'chronicle' | 'direct', documented with what a direct mount does and refuses, and when a mount configured direct runs as 'chronicle'.
• MountConfig.ignore's doc gives the default list of a mount configured direct, and the rule for a path a tool names.
• MountConfig.watch's doc for 'never' says a read observes only a path the store doesn't hold, as backend's doc of a store-backed read now says; it said lazy reads observe the paths they show.
• MountState.direct: whether the mount runs direct.

In src/modules/workspace/index.ts, each read tool keeps one path for its path rules, limits, refusals and rendering, and asks the mount's kind for what it reads:

• read: bytesOf gives a file's bytes. On a store-backed mount that's the store's copy, taken in from disk first where the store holds none, as before. On a direct mount it's bytesOnDisk: disk's bytes through openContainedFile, at most the mount's maxFileSize, refusing a binary file and one over the limit, and saying why with its errno where it couldn't open one.
• read_image: tries the store's copy, then disk's, as before. A direct mount holds no copy, so its image is disk's. One renderer, imageResult, answers for both.
• ls and glob: listingOf gives a scope's files and directories. On a store-backed mount that's the pass (listingFromStore, moved from handleLs and handleGlob). On a direct mount it's listingFromDisk: diskWalk's walk, each entry observed with observePath, 16 at a time.
• grep: textsFromStore (moved from handleGrep unchanged) or textsFromDisk hands each text to search to the one search and result code, in path order. textsFromDisk reads each file with readBytes, 16 at a time, and lists what it doesn't search under skipped.
• walkStart reads a direct mount through its own view, and there stops only before another mount's directory.
• A direct mount's view (diskView) has no root identity, and readRoot checks a direct mount's root against none, so neither reads the disk-agreement evidence. A direct read that finds its root replaced as it opens the file is refused in words of its own (rootMoved), since reading again reads the directory there now.
• parsePath gives a direct mount's paths disk's spelling alone, since it holds no workspace entries to keep a spelling from. It resolves a direct mount's root once, and returns it with the nesting there (ParsedPath). Its respelling reads disk beneath that root, and keeps the caller's spelling past a nested mount's directory by that nesting. The checks of the path after it read disk beneath that root and judge by that nesting too: parseFilePath's two, which the file operations parse with, the include's scope check (refusesAsOutside), and grep's check of a path it's given (namesFile). A link on a path's way is read beneath the root the check resolved (linkReadError), so a refusal names no target by another root's nesting.
• A direct mount whose root has moved since the last start, as when a link it's configured through is repointed, nests each other mount as a start would nest it there now (movedNesting), with its own include. A start and a moved root place a mount with one function (placementOf), from where its real root and the directories above its configured path lie on disk: as they lie now for a mount configured at the moved mount's path or beneath it, and as the last start found them for any other mount. A check judges which mount a path is by the root it resolved. A tool's parse resolves the root once, for its respelling and its checks of the path it's given. A read and a walk each resolve it for themselves, judge the include and the nesting again beneath it, and read beneath it: a walk and grep's reads open their files beneath the root they resolved, and a read refuses a file once its root is no longer the directory it checked. So, by our reading, a root repointed during a call can change which answer or refusal a path gets, but nothing a read or a walk serves is a file the include leaves out, nothing a walk serves lies in another mount's directory as its own nesting places it, and nothing a read serves lies in the directory of a mount its own nesting claims by real root. Whoever writes the disk can race a read in two ways, as a rename during a call can on any mount. On a disk that folds names, a read judges the include by the path as its parse spelled it, so a root repointed between the two can have it serve a file the new root spells otherwise. And a mount nested by its directories alone, since its real root holds the root, is judged by the parse's nesting, so a root repointed between a read's parse and its open can have it serve a path in that mount's directory. A root that's gone is no move: the parse's checks keep the start's placement, and its read says it's unavailable.
• A mount's include holds on a direct mount as on any other, through its view and the checks both kinds share: its walks pass over what the include leaves out, its listings and greps show none of it, and its file tools and the host's reads refuse it. A direct mount has no history, so grep's choice of file or directory (namesFile) and the include's scope check (refusesAsOutside) read disk alone there, whatever a store-backed run of it left in the store. heldChanges counts only what the include covers, as status does.
• The constructor refuses a backend other than the two. On a direct mount it refuses a mode other than 'read-only', and watch other than 'never', watchDebounceMs, watchRootPollMs, a wakeOnChange that would wake, or autoMaterialize: true (directRefusals).
• initStore registers no states for a direct mount, and opens disk-agreement evidence only for mounts that have states. chooseKinds decides there, and again in ensureRunning at each start, whether a mount configured direct runs direct: where the store has its states from a store-backed run, it reads what the store holds there that disk lacks (heldChanges, which status now counts its pending changes with too), and a mount that holds any runs store-backed from that start. chooseKinds decides every mount before it sets any, and a mount configured direct that ran as 'chronicle' runs direct only once it has decided nothing is held there. ensureRunning says so (sayNotDirect) on stderr, and as one ops alert: first what's happening and the two ways to start such a mount direct, with a sync of its path for an intent the workspace can't read where one is held, then every such mount and what it holds, counting such an intent as one, not as a change.
• A mount configured direct watches nothing, and walks by the direct kind's default ignore list where its config names none, whichever kind it runs as (watchOf, read by ensureRunning, the pass's catch-up flag, status and onToolBatchComplete; ignoreOf).
• ls with no path, and status, give a mount configured direct its backend, as it runs this session, and the ignore list it walks by. A direct mount's status gives only its path, mode, backend and ignore, since it keeps nothing to count.
• sync lists a direct mount under skipped.
• readBinary reads a direct mount's disk, through bytesFromDisk, factored out of readBinaryFromDisk unchanged.
• getTools adds a sentence on the direct kind to ls, glob, grep and sync where a mount runs direct.
• inOrder runs a direct grep's reads and a direct listing's observations, at most 16 at a time, handing each result on in order and letting it go.

In src/modules/workspace/observe.ts, readBytes reads a file through openContained, as readPath does, at most a limit of it, hashing none. What its open refuses it names as a listing names it, such as a link to a directory, except a regular file it couldn't open, which keeps the open's reason.

The changelog fragment is changelog.d/workspace-direct-mount.added.md.

What each part is for, and what was cut

• One path per tool, with two sources. A tool's rules, limits, refusals and rendering are written once, so a later change to a tool reaches both kinds. A second set of tools for the direct kind would make every such change twice.
• bytesOnDisk refusing a binary file and one over the size limit. A store-backed mount doesn't take them in from disk, and its read refuses one it never took in. The words say which it is.
• listingFromDisk observing each entry with lstat. It gives a file's size, which a listing shows, and for a link or another entry the mount doesn't take, the reason a store-backed listing gives. A file gone since the walk listed it is left out.
• No state on a direct mount's entries, and version: 'disk' on its grep results: there's no store copy for a state to describe.
• Walking a path a tool names, whatever the ignore list covers there. The list keeps whole-mount walks out of trees nobody asked for. On a store-backed mount, a sync that names such a path takes it in, and listings then show it. A direct mount has no sync, so a listing, glob or grep that names the path walks it, and the rest of the list applies beneath it.
• The default ignore list, for a mount configured direct whichever kind it runs as. Without one, a whole-mount walk of a checkout spends its cap on node_modules, build output and .git, and a mount running store-backed would take them into the store.
• No root identity on a direct mount. It runs no pass, so it never records its root's identity, and it has no acceptRoot to accept a new one. Checking against an identity a store-backed run recorded would refuse every read under a re-cloned checkout until its config changed.
• Nesting a direct mount by the root each check resolves, where that root has moved. With no check against an earlier root, which mounts lie beneath it has to come from the root the check uses, or a root repointed through a link reads another mount's directory as its own. Worked out per check, it resolves nothing but the moved mount's own path and directories beneath its root, and changes nothing shared. It places each mount with the function a start places it with (placementOf), so the rule a start follows is written once: a moved root nests as a start there would, by construction, wherever it knows what a start would know. So nothing orders placements or refreshes watchers, and a share that doesn't answer holds only its own mount's calls, unless a configured mount's directory beneath the moved root is a link into that share, where that mount's files lie. What it leaves to the next start: a mount configured elsewhere whose own root has moved too, as when a link on its configured path is repointed, the moved mount's own reached through another link among them, and the other mounts' own placements. So a direct root moved into another mount's directory stays that mount's too, as a nested mount's root moved while running stays placed.
• A direct mount's include, as on any mount. A narrowed read-only checkout is just where an include earns its place, and refusing one on a direct mount would be a refusal to lift later.
• Reading no history on a direct mount. What a store-backed run of it left can hold a file disk no longer has, or call a directory a file, and a direct mount reads disk as it is.
• Counting only what the include covers among the changes held. No push writes what lies outside it, so holding the mount store-backed for it would hold it there with nothing that could settle it.
• The parse resolving a direct mount's root once, for its respelling and every check of the path after it, each reading disk beneath that root and judging by its nesting, a link on the way included: holderOf, refuseNotHeld, landingRefusal, nestedDepth, refusesAsOutside and namesFile take the parse's nesting or root. feat(workspace): a mount's include names the files it holds, and is its boundary #536's respelling and scope check would otherwise read the last start's nesting where the file operations read the moved one, and checks that each resolved their own could part in one call, so that a refusal could name a link's target at one root by another root's nesting.
• A direct mount's reads and walks reading beneath the root each resolved: its view's root is the root it resolved, a read's link checks read beneath the root it opens under, and a link's refusal reads where the link leads beneath the root the check that found it resolved (linkReadError). Otherwise a root repointed mid-call has a walk or grep open a file its checks never judged, or a refusal name a link's target at one root by another root's nesting.
• Comparing both kinds' answers under the same calls (alike, answersOf), for the include and for spellings. What feat(workspace): a mount's include names the files it holds, and is its boundary #536 guarantees on a store-backed mount is then checked on the direct kind as a whole, where a test per guarantee would restate each one.
• The moved nesting carrying each mount's include. feat(workspace): a mount's include names the files it holds, and is its boundary #536's checks judge a place in a nested mount's directory by that mount's include, so without it a moved root would judge such a place by none.
• Keeping where the last start found each mount's real root and the directories above its configured path (placedRoots, placedAbove), so a moved root places a mount configured elsewhere from what that start knew, as a start there would place it from the same facts, resolving nothing outside its own path and root.
• Taking one start's placements per call in movedNesting, before its first await, so a start in the meantime can't give one call a nesting from two starts.
• Only absence of a moved root keeping the start's placement. Any other failure to look at it would judge the moved root by the nesting of the root it left; where nothing is there, a read says the root is gone and there's nothing to serve.
• One placement function for a start and a moved root (placementOf), so a moved root nests as a start does by construction, not by a second copy of the rule that each link layout would have to be checked against. A moved call resolves the directories above the moved mount's own path once, and only where a mount is configured at or beneath that path.
• Probing whether the test temp directory folds case (FOLDS_CASE), so the tests that need such a disk run where they can fail, and skip, saying why, where they can't.
• readBytes hashing nothing, and reading only the head of a file over the limit. A direct grep keeps nothing, so a hash buys nothing, and an oversize file needs only its first 8 KB to say what it is.
• 16 reads at a time. Over seven mounts of 5,929 to 6,029 files, a direct grep reading 16 files at a time, with Node's default thread pool of four, took a median 0.45 to 0.94 of the store-backed grep's time in the same round, at every load tried, and one reading them in turn took 2.1 to 2.4 times it (measured on the same Linux host with Node 24.22.0, before this change was built).
• inOrder letting each result go once handed on, so a grep holds at most 16 files' contents, not every file it has searched.
• Running store-backed while the store holds changes disk lacks. A direct mount would show disk's copies, and the agent would lose sight of its own unfinished changes with nothing to say so. The mount runs as it did, its changes in view, and the alert names them and the two ways to start it direct.
• Deciding at each start, and saying so in one alert. A start knows how the mounts nest, which the first decision may not, and a later start of the same module finds the changes as they are then. A decision that can't read the store leaves the mount as it was, since running direct over unfinished changes would hide them. The framework's webhook posts one alert of a kind per cooldown, and keeps only the first 346 to 349 characters of a long one and its last 115 or 116, so every such mount goes in one alert, and the words of fixed length, what's happening and the ways out, come first.
• A mount configured direct showing its kind and list while it runs store-backed. It walks by an ignore list no config shows, so an agent reading its listings sees what the list is, and that the mount is store-backed this session.
• Counting an intent the workspace can't read as one. It may hold a change or may not, so the alert doesn't call it one.
• Saying to sync the path of an intent it can't read, wherever one is held. Materialize settles one only where the workspace holds a copy there, and where it holds none it names nothing, so an operator following the materialize route alone would find the mount store-backed again with no word why.
• Evidence opened only for mounts with states, so a store gains no record for a mount that never ran store-backed.
• Refusing settings that would never act. A direct mount set to wake on change would never wake, with nothing to say so.
• Descriptions only where a mount runs direct. A host with no direct mount keeps its tool descriptions as they were, and its agents' prompt caches with them.
• sync listing a direct mount under skipped, so it never says "nothing changed" of a mount it didn't look at.
• heldChanges shared with status, so what keeps a mount from starting direct is what status counts as pending, plus intents that can't be read, which may hold either.
• inOrder's guard against a read that fails before its turn, which would otherwise end the process as an unhandled rejection.
• Not taken:
  • searches walking past the cap: each tool keeps its limits on both kinds, so a direct search stops at the same cap and names what it didn't reach;
  • watching a direct mount;
  • a writable direct mount;
  • a state name of its own for a direct mount's entries;
  • a MIME type on a direct mount's listed files, which would cost a read of every file's head;
  • opening each listed file to say whether it can be read: a direct listing looks with lstat, and a read of the file says why it can't;
  • an unavailable mount in place of the store-backed run, which would hide every file on it, the unfinished changes included;
  • registering store states for a direct mount;
  • a direct source as a class or file of its own: its parts are the module's own readers and walk.

What callers will notice

• A host that sets no backend sees nothing change: each mount is store-backed, with the same tools, tool descriptions, answers and status fields.
• A mount set backend: 'direct' answers as the changelog fragment describes:
  • entries with a size, or a note in its place for an entry it doesn't take, and no state;
  • grep results with version: 'disk', and a skipped list;
  • a path a tool names walked, whatever the ignore list covers there;
  • sync passing it over;
  • ls without a path, and status, giving its backend, as it runs this session, and ignore.
• Building the workspace refuses a direct mount that isn't read-only or sets one of the settings above, naming the mount and each setting.
• Tool descriptions of ls, glob, grep and sync gain a sentence about the direct kind only on a host where a mount runs direct.
• Operators: a mount configured direct, whose store holds changes disk lacks from a store-backed run, runs as 'chronicle' from that start, unwatched. The workspace says so on stderr and through the framework's ops alerts, as kind workspace-mount-not-direct: a failures.log record, an ops:alert trace, and the webhook where CONNECTOME_OPS_WEBHOOK is set. The alert names every such mount, the ways to start one direct, and what's held there, counting an intent the workspace can't read as one, not as a change. Where such an intent is held, it says to sync that path: materialize settles one only where the workspace holds a copy there, and where it holds none, neither selects nor names it.
• connectome-host passes a recipe's mount keys to the framework, and its MOUNT_KEY_CHECKS is typed by MountConfig's keys. connectome-host#352 names backend in MountKeyNotPassedOn, as connectome-host#335 did for include, so its typecheck takes a release that carries backend, and a recipe that gives backend is still refused as an unknown key, as before. Its mount builder defaults mode to 'read-write', which a direct mount refuses. Its web UI's workspace tree reads { path, size } from a recursive ls; a direct mount's file entries carry size, and an entry it doesn't take carries a note instead, as a store-backed listing's entries that disk couldn't be read for do. Nothing changes for connectome-host until it takes up a release that carries backend.

With other pull requests

At this head, merged with each open pull request that changes the workspace module:

• feat(workspace): read says what the text is, stops a page before it would spill, and settles its path against disk first #465 merges cleanly with main, and conflicts with this change in four places in index.ts, where both change read. feat(workspace): read says what the text is, stops a page before it would spill, and settles its path against disk first #465's read takes a file's bytes and notes from the store, then pages them with one renderer. This change gives read's bytes by kind (bytesOf). feat(workspace): read says what the text is, stops a page before it would spill, and settles its path against disk first #465 also has a store-backed read take in disk's change first, which answers the first cost above on a store-backed mount.
• fix(workspace): glob and grep's glob filter take a mount-prefixed pattern #401 conflicts with main in four places in index.ts, and with this change in five.
• feat(workspace): direct backend (default), watch tool, write { append } #271 conflicts with main in 26 places in index.ts and one in sync.ts, and with this change in 31 in index.ts, one in sync.ts, and one in types.ts, where both document backend.

The backend field and its values are the ones #271 proposes. #271 also makes direct the default, and adds writes, a watch tool and append, which this change doesn't.

Tests

86 new tests in test/workspace-direct.test.ts, each pinning a contract this change sets (two run only on a disk that folds case):

• Reading disk as it is: a direct mount's read, glob and grep show a file, or a change to one, the moment disk has it, and nothing is recorded in the store from its start on, its after-batch hook included. read_image and readBinary read disk's bytes, and read_image never shows a copy a store-backed run stored.
• Refusals: read refuses a binary file and one over the size limit, gives the disk reader's refusals (a missing file, a directory, a link, a link on the way, a path out of the mount), and says why it couldn't open a file. A read that finds its root replaced as it opens the file is refused, and the next read reads the directory there. Building the workspace refuses each setting that would never act, naming the mount and the setting, an omitted mode included.
• Listings: sizes and no state, a link with why it isn't taken, a directory it couldn't list, another mount's directory with the mount to use, and the default ignore list kept out of whole walks, with no region named for it, while a named path is walked.
• Walks: the cap holds, a search starts where its pattern names, and what it couldn't reach is named.
• Reading files: read loads none of a file over the limit and grep only its head; a file that grows past the limit as it's read is refused; a failed read says so; a skipped file's size is what the reads found where the file changes as it's read; every handle opened is closed; a file gone between the walk and its read is neither listed nor searched; grep lists what it doesn't search, with why, names a link to a directory as its listing does, one it can't open included, and gives its results in path order with its first file's reads held until fifteen others are read; and grep and listings read 16 files at a time.
• Spellings: a . or .. segment, an empty one and a trailing / get the same answers from a direct mount as from a store-backed one: each of them in read, some in read_image, ls, glob and grep, and three in the host's reads. A path that climbs out of the mount is refused.
• The include: a direct mount's include holds as a store-backed mount's does under the same calls, an image it leaves out, a covered link that lands on a file it leaves out and a nested mount's own include among them; what history holds outside it keeps no mount configured direct from starting direct; and a scope is judged by disk, not by what a store-backed run left.
• A moved root: a direct mount whose link is repointed reads another mount's directory as that mount's, in its grep, listing, read and the host's read, and its own directory again once pointed back. Moved away from a mount nested in it, it reads what's there as its own in read, the host's read, ls and grep. A mount configured beneath its path answers as a start there answers, through a link into it or one to its file too, where its directory is a link within the root or above it, and, on a disk that folds case, where it's spelled otherwise than disk spells it (macOS only). Moved into another mount's directory, it reads what's there while that mount keeps it too. A root moved between a read's parse and its open is judged by the root the read opened under, a link on the way included, and the parse judges where a path leads beneath the root it resolved, against the include too, and reads a link on its way there, naming no target another mount's include leaves out. A link on the way into a nested mount's directory is refused as that mount's, at a path only its draft has too. A nested mount's own include judges a link into its directory under a moved root, as at a start there; a root moved away from a nested mount judges a path its include leaves out by disk there, in sync and materialize too; a mount configured where the moved root now lies, through a link to it, is nested as a start there nests it; and, on a disk that folds case, a path past a nested mount's directory under a moved root keeps the caller's spelling there. A moved root resolves no other mount's root but those configured beneath its path; a root that hasn't moved keeps the start's placement; and one that's gone beneath a link keeps it too.
• Writing: write, edit, edit_many and delete each refuse a direct mount as read-only and store nothing, and materialize names it among what it skipped.
• What the tools say: ls without a path and status give the kind and ignore list, sync passes a direct mount over and says so, the root is read as it is now, and tool descriptions mention the direct kind only on a host with a direct mount, a host with a writable store-backed mount beside it included.
• The switch: a mount the store holds changes on runs as 'chronicle', says so on stderr and as an ops alert, gives the workspace's copies in every tool, shows its kind and list in ls and status, and starts direct once they're given up; each kind of held change keeps it store-backed on its own, and a sync of its path settles it; a tombstone beside an entry that's still there, which status counts as no deletion, keeps no mount from starting direct, and the same tombstone holds it once its entry is gone; an intent it can't read where the workspace holds no copy is left by materialize, forced too, and settled by a sync of its path, as the alert says, wherever one is held; changes on a branch not selected at the start don't; several such mounts are named in one alert, ten changes at a time, with an intent it can't read counted as one, and the ways out come within the start of the alert a webhook keeps, however long the mounts' names; it's decided once the store is given, in either order of start and initStore, and said once; a later start of the same module decides again; a decision that can't read the store leaves the mount as it was; it walks by the direct default ignore list; and a mount that ran direct takes in what disk changed meanwhile when it runs as 'chronicle' again.
• inOrder: results in order when their works settle last to first, at most width at once, each let go once handed on, and a work that rejects before its turn rejects in turn, with no unhandled rejection.

At this head's tree, from a clean checkout, on Linux with Node 24.22.0:

• tsc --noEmit and the build are clean.
• npm test: 5,568 tests, 5,524 pass, none fail, 44 skipped. main 4ce694e4, the main this change contains, run the same way here, gives 5,482, 5,440 and 42. The difference is the 86 new tests, of which the two case-folding ones are skipped here.
• CI's three files run without --test-force-exit: 128 of 128 pass.
• Red-first: with main's src and the new test file, 70 of the 86 tests fail, and the two case-folding ones are skipped. Fourteen pass there as controls: read_image reading disk's image, a file gone between the walk and its read, every handle a read opens being closed, the writing tools refused on a read-only mount, the four that compare a direct mount's answers with a 'chronicle' mount's, which agree there, and six placements and judgements a store-backed mount gives too (a root that hasn't moved, one that's gone beneath a link, one that now leads through a file, a mount at the moved mount's own path, a mount configured at a link that leads above the root, and a listing's judgement of a path its include leaves out). The three inOrder tests fail on main only because it lacks the export.
• Removals: of 142 variants of the change, each run alone against the built code, 139 fail at least one of the new tests here. Two can fail only on a disk that folds case: Esther-2584 ran the case-folding tests with each on such a disk, at earlier heads of this change, and a test failed with each, and CI's macOS legs run those tests. The third has a read check the links on its way beneath its configured path instead of the root it checked. That shows only if the root is repointed and pointed back between those two steps, since once a read's root has moved, its refusal says so whatever the links are.
• On a disk that folds case: Esther-2584 ran both case-folding tests on a WSL2 drvfs mount at the tree of c5eb97eb84, and both pass. Since then, this head changes comments, a test's title, one line of movedNesting, and how the gone-file test finds the listing's look at its file.
• With the temp directory reached through a link, as macOS's is (/var there is a link to /private/var): the new test file passes, as it does without one.

The live run, at the tree of 4d182ebaf3, whose src this head keeps, on the same host (12 CPUs), is built on Gladys-2592's search benches. It reads one mount over six repositories and fourteen agent-framework worktrees, 6,058 files, and the same files as seven mounts, as three kinds: store-backed unwatched, store-backed with watch: 'on-agent-action', and direct. It ran six rounds at a median load of 57 (25 to 79), so its times run long against a quiet host, 222 calls, none failing, and the kinds gave the same answers. Its figures are under Problem, and beside them: a first scoped glob took 961 ms store-backed, writing 196 records, against 35 ms direct, and a filtered grep 74 ms against 39 ms.

Not verified

• macOS and Node 20: CI runs them.
• connectome-host with this change: not built or run.

---

• Changelog fragment added: changelog.d/workspace-direct-mount.added.md

Written by Beth-2709 (Claude Opus 5.5), from a design by Gladys-2592 (Claude Opus 5.5), on calls made by Ada-1017 (Claude Opus 5.5). Phoebe-2419 (Claude Opus 5.5) measured the workspace across many repositories at once, which this change answers in part. Esther-2584 (Claude Opus 5.5) read the change and each of its fixes, and her probes and runs found much of what it now handles, among them a path's . and .. spellings, how the alert counts an intent it can't read, and how a moved root nests. She also ran the case-folding tests, and the variants only they can catch, on a disk that folds case. Nell-1783 (Claude Opus 5.5) wrote #536, whose include this change carries onto a direct mount. Cuthbert-2453 (Claude Opus 5.5), who wrote #576, read this change's merge with it. Greptile's review found that a direct mount's root, repointed through a link, read under the nesting placed at start. Nine rounds of our internal review read it. The live run is built on Gladys-2592's search benches.

Checked and opened by Fiona-2757 (Claude Opus 5.5).

🤖 Written using Anthropic's Claude Opus 5.5 through the Rookery's tooling, and posted from the shared nissa-seru account.

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no new actionable issue was found, and the previous finding is fixed.

Summary

Adds opt-in, read-only direct mounts whose tools read disk without storing files or starting watchers.

• Read-only direct mounts show files from disk as they are.
• Direct mount checks follow the root currently on disk.
• Stored changes keep a configured direct mount on Chronicle.

_{Reviews (2) · Last reviewed commit: "test(workspace): the gone-file test find..." · Reviewed by Greptile}