9b9b45e65e
Asked what a workspace contained, an agent described one subfolder as the
whole project. `glob {"pattern": "*"}` matched 10030 paths across 22
top-level entries and the inline page was the first 100 of them, all under a
single unpacked archive.
Three properties compose into that page: a pattern with no `/` matches
basenames at any depth, so `*` means the whole tree rather than its top
level; `--sort=modified` orders oldest first, and unpacking an archive
restores timestamps that predate everything the user wrote; and the page was
the head of that order. Each is defensible alone, and together they make the
most ordinary request an agent receives produce a confident wrong answer.
A result within `globMaxResults` is unchanged — shown whole, in
modification-time order. Beyond it the page is filled round-robin across the
complete result's top-level entries, so one subtree cannot own every slot,
and the footer states that the page was sampled rather than taken in
modification-time order. Measured on a 24-entry, 716-file reproduction, the
head of 100 reaches 7 top-level names and the sampled page reaches 21. The
spill artifact still holds the complete sorted list.
The guidance and schema stop steering away from `ls`, state the any-depth
pattern rule, say results are files and never directories, and point at
`list` for a directory's contents.
fs/ - filesystem capability family
English | 中文
The filesystem stack: a provider seam (text IO + atomic mutation with an optional version guard), a local implementation, a policy gate plugin (observed-state + read-before-edit + version-guarded write/edit), the model-facing file tools + executor, and the bash-backed discovery tools. All product packages.
| Package | Role | ctx key |
|---|---|---|
fs/ |
Provider seam: text IO + atomic mutation primitives (optional version guard); owns the fs/* policy events |
ctx.fs |
fs-local/ |
Local-filesystem FileSystem implementation |
(registers ctx.fs) |
fs-sandbox/ |
Sandbox-enforcing FileSystem: extends fs-local and fences write/edit by the per-call mode + workspace root policy (read-only denies, workspace-write contains to the session workspace + temp roots), reads pass through |
(registers ctx.fs) |
fs-policy/ |
Policy gate plugin: observed-state + read-before-edit + version-guarded write/edit, via the fs/* event gate |
(no service — fs/* listeners) |
tool-fs/ |
Model-facing read/write/edit tools AND the executor (reads via ctx.fs, owns read windowing, dispatches fs/*); preserves filesystem semantics for session-cwd-relative paths and advertises sandbox escalation fields when the mounted ctx.fs confines |
(registers on ctx.tools) |
tool-fs-search/ |
Model-facing glob/grep discovery tools when rg is available on the bash executor PATH, backed by fixed ripgrep commands through ctx.bash, NOT by ctx.fs provider methods |
(registers on ctx.tools) |
The interface lives at fs/fs/. A sandboxed, remote, or project-scoped filesystem backend can replace fs-local without touching the seam, the policy gate, or the model-facing tool schemas — fs-sandbox is the first such replacement (an in-process path fence over the shared sandbox mode; see the cross-family fs sandbox Agent Note). The policy (fs-policy/) is a plugin that participates only through the fs/* event gate, not a service the tool injects — so dropping it gracefully loses the policy and leaves the unconstrained bare provider rather than breaking the tool. A deployment that loads tool-fs/ is expected to also load it. The mode fence and the read-before-edit gate are orthogonal and compose. Discovery (tool-fs-search/) deliberately does NOT extend the provider seam: search is a process-backed rg workflow on the bash executor, so filesystem backends stay free of a universal search contract; its tools register only when that executor can find rg, and its results are follow-up-readable when the bash workdir and the read root are the same workspace (the co-located deployment its README documents).
No timeouts on file IO
read/write/edit take no timeoutMs, and the provider seam arms no deadline — unlike bash and web (which consume @deepseek-ai/dsh-timeout) and the bash-backed glob/grep (whose declared timeoutMs is enforced by @deepseek-ai/dsh-timeout-policy): those are process-backed, where a deadline can really kill the work. A local syscall is best-effort-abortable at most: a timeout could not force an in-progress fsync/rename to stop, so a deadline here would be a knob that cannot deliver on its promise. Adding one would also be an implicit default in the exact place explicit-over-implicit forbids. Both reference agents (Claude Code, Codex) leave file IO untimed for the same reason; cancellation still propagates through the tool-execution signal for best-effort abort at syscall boundaries.