[nplez1]

	Files	Added	Deleted	Net
Test	9	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​541	$\color{#cf222e}{\Huge{\mathbf{−}}}$​22	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​519
Prod	21	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​647	$\color{#cf222e}{\Huge{\mathbf{−}}}$​154	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​493

ELI5

The file filter in the file browser was reading only the first page of a very long list of files, and it never said so — so a file further down that list came back as "no files match this filter". On a local workspace it was worse than that: the filter threw away its own results and returned nothing for any search.

Now the filter asks the computer for the files that match what you typed, wherever they are in the workspace. When there are more matches than it will show, it says how many it found and how many it is showing, and asks you to type a bit more.

What Changed

Before, on a local workspace:

• Typing anything into the Explore pane's Names filter returned zero rows and "No files match this filter" — every query, regardless of whether the file existed. Reported against a file three directories deep in a large repository, which returned nothing for both drover and drover.eve.
• Filtering ran over a full workspace listing capped at 20 001 paths, truncated in ripgrep's traversal order, with the truncation flag never rendered. On a large workspace a real file could read as "no match" with no hint that the search was partial.
• Quick Open ranked that capped listing in the renderer.

After:

• The local filter returns matches from anywhere in the workspace. With more matches than the page holds it shows "Showing the first N of M matches — add more of the name to narrow it down".
• When the host cannot count matches (SSH, older remote hosts) it shows "Only part of this workspace was searched — add more of the name to narrow it down". "No files match this filter" is now reachable only for a scan that completed.
• Quick Open takes the same host-side path and renders the flag the host reports, instead of inferring truncation from files.length >= 20 001.

Mechanism

• Matching moves to the execution host, which is where SSH and remote runtimes already did it; the local window was the only one filtering a truncated page in the renderer.
• QuickOpenPathRanker gains a sibling, NameFilterPathMatcher, in src/shared/quick-open-path-search.ts. The Explore filter keeps its documented substring-AND semantics (it is deliberately not pointed at the fuzzy ranker), counts every match, and retains the lexicographically first page so the tree stays a stable sorted prefix rather than an arbitrary subset.
• searchQuickOpenFilePaths takes a mode (quick-open | name-filter) over one ripgrep pass; the shared tokenizer/predicate is now used by both the host matcher and the renderer projection, so the two cannot drift.
• New fs:searchFilePaths IPC returns { files, totalCount, truncated } and shares the fs:listFiles cancellation registry, so a superseded keystroke kills the previous scan. searchRuntimeFilePaths uses it for a local workspace; an empty query keeps the unscoped listing, so Quick Open still lists files before you type.
• Remote runtimes and legacy inventories now pass through the totalCount their replies already carried; their wire format is unchanged.

QUICK_OPEN_LISTING_MAX_RESULTS is untouched.

Why

The reported symptom had two independent causes, and the tempting fix — remove the 20 001 limit — is the wrong one:

1. The filter's projection was gated on a query-scoped listing (resolvedQuery === query). A local listing is unscoped (resolvedQuery === undefined), so every local query resolved to []. This alone explains zero results for any query.
2. Filtering then depended on a truncated listing. The cap is an OOM bound from fix(memory): bound OOM-prone accumulators across Orca stablyai/orca#10179: QUICK_OPEN_READDIR_MAX_FILES aliases it and the readdir fallback throws past it, the relay clamps to it via resolveQuickOpenResultLimit, and the runtime command path imports it. Raising it would also re-introduce the cost it exists to prevent — the renderer fuzzy-ranks the whole retained array per keystroke.

So the bound stays, and a filtered query stops using the bounded listing at all: it gets its own query-scoped search with a smaller page. That is the design the remote paths already used, now shared with local.

Alternatives considered: raising the cap (rejected above); client-side paging with cursors (rejected — paging over a mutating filesystem needs snapshot tokens and host-side caches, which is the memory the bound exists to bound, and typing one more character is better UX than a "load more" button); streaming results over a new RPC opcode (deferred — docs/reference/remote-wire-compatibility.md Rule 2 says a new stream opcode must be capability-negotiated, which is the follow-up stage).

Design, contract, staging, and the test strategy are written up in docs/reference/file-path-filtering-at-scale.md (linked from AGENTS.md, and allow-listed in .gitignore the way that file's own convention requires for a tracked reference doc).

Linked Issue

No issue — reported directly, fixed on fix/explore-file-filter-partial-results, which is cut from origin/main so its delta is this one commit.

Visual Proof

Pending — no before/after captured. This change is visible in the Explore pane (a partial-result notice replaces a false "No files match"), but this worktree has no rendered-app harness, so it is verified at the unit and integration level instead: see Testing. Both states are easy to capture for anyone with a workspace over ~20 000 files.

Testing

• pnpm tc — clean (node/cli/web projects).

• 9 780 tests pass across src/renderer/src/components/right-sidebar, src/renderer/src/runtime, src/renderer/src/web, src/main/ipc, src/relay (1 073 files, 18 skipped), run on the origin/main base.

• src/main/ipc/filesystem-search-file-paths-real.test.ts is new and drives real ripgrep over a temp workspace: 20 002 filler files plus src/a/b/drover.eve_schema, asserting the query-scoped name-filter search returns that file with totalCount: 1 — the reported scenario. Plus a broad-query case (bounded sorted page + exact count + truncated) and a fuzzy-mode regression case. The suite skips itself when no rg binary is present.

• The gate that caused the zero-rows bug has a regression test that fails on the previous code: use-file-explorer-name-filter.test.ts → "filters a local full listing that no query produced".

• check:code-quality:changed, check:max-lines-ratchet, verify:localization-catalog, verify:localization-extraction, check:readme-local-links — all pass.

• Platforms: macOS only. The SSH/relay and runtime paths are deliberately unchanged, and the added code is path-agnostic (no new shell, shortcut, or path handling). Windows/Linux and a real SSH host were not run locally — CI covers the unit matrix.

• Not run locally: pnpm lint in full, pnpm build.

• I manually tested these changes locally

• Automated tests added/updated, or explained why not below

AI Disclosure

Implemented with an agent (DeepSeek v4.1 Flash in the pi harness), with a design consultation from Kimi K3 (Fireworks) and a review pass from a stronger advisor model. The maintainer reported the bug and chose the approach among the presented options.

Review

Agent skill upstream boundary

• Not applicable, or this change follows docs/reference/agent-skill-sharing-upstream-boundary.md and copies or mechanically translates no upstream skill-installer source, tests, fixtures, registry entries, path tables, comments, or documentation.

Notes

• Security: the new IPC channel authorizes through the same resolveAuthorizedPath as fs:listFiles, honours the same excludePaths (nested worktrees) and the same hidden-dir/node_modules blocklist, and reuses the sender-scoped cancellation registry. No new file access is granted.
• Cross-platform: verified only on macOS. wslAwareSpawn and the existing path normalization are untouched; the new matcher compares lowercased /-separated relative paths, as the renderer already did.
• Remote SSH / mobile: the SSH path is unchanged (it still returns truncated without a count, which the pane now reports honestly). Paired-web gained a files.searchPaths implementation for the new API method. An exact name-filter total over RPC, with version negotiation and a legacy fallback, is stage 2 in the design doc.
• Backwards compatibility: fs:searchFilePaths is a new channel (same-version local IPC). Remote wire format unchanged; totalCount was already in the runtime reply.
• Performance: a local keystroke now triggers a debounced (120 ms) ripgrep scan that is aborted on the next keystroke, instead of filtering one capped listing client-side. Host memory is bounded by the page size, not the workspace size — 5 000 paths for the filter, 32 for Quick Open — and the renderer no longer holds or fuzzy-ranks a 20 000-path array per keystroke.

Checklist

• This PR is small and focused
• I explained what changed and why (ELI5, the user-facing before/after, the mechanism, and why over the alternatives)
• Before/after screenshots or videos attached for UI changes, or N/A with reason
• Self-reviewed for correctness, security, and performance
• Cross-platform, SSH/remote, and path/shortcut impact considered (or N/A)
• pnpm lint, pnpm typecheck, pnpm test, and pnpm build pass (or CI will cover; local preferred)