Path listing hides every dotfile and node_modules unconditionally, so file search cannot find .github/workflows/ci.yml

[andrewkchan]

Human comments

This will be useful for file tree plugins to be more customizable

---

Summary

host.list_paths skips any entry whose name starts with ., plus node_modules and symlinks, with no way to opt in. Because BB's own file search runs through that command, quick-open cannot find .github/workflows/ci.yml — a file BB reads and previews perfectly well through host.read_file. The rule is hardcoded in the daemon's walker, not derived from gitignore, and callers (first-party or plugin) cannot override it.

I hit this building a file tree in a fileOpener plugin, but the plugin is incidental: the same gap is visible in BB's own UI, and that is what the repro below uses.

Versions and environment

• bb dev build from source at 6be45053be92f964895038fc374a45e759087479 (main), plus bb 0.38.0 desktop (same behavior).
• macOS 14 (Darwin 23.3.0), Node v26.7.0.
• Repository under test: this one (.github/workflows/ci.yml is present).

Steps to reproduce

1. Open a thread whose environment is a checkout of this repo.
2. Open the secondary panel's file search (+ → file search) and type ci.yml.

Or against the API directly, which is what I did:

curl -s "http://127.0.0.1:<port>/api/v1/environments/<envId>/paths?query=ci.yml&limit=5&includeFiles=true&includeDirectories=false"

Expected vs actual

Actual — .github/workflows/ci.yml is absent, and the four fuzzy matches returned are all unrelated:

query ci.yml     -> 4 results: apps/mobile/e2e/flows/phase4a-conversation-rows.yaml,
                               apps/mobile/e2e/flows/phase4b-actions.yaml,
                               apps/mobile/e2e/flows/phase4b-interactions.yaml
query workflows  -> 5 results: plugins/workflows/README.md, plugins/workflows/package.json, ...
query AGENTS.md  -> 1 results: AGENTS.md            # control: the endpoint works

Expected: .github/workflows/ci.yml appears for ci.yml. It is an ordinary YAML file, and BB is otherwise perfectly happy with it — reading the very same path through the host file API succeeds:

read .github/workflows/ci.yml -> OK, 7794 chars, sha d9d35944bf59

So one host command serves the file and another refuses to admit it exists.

Evidence

The exclusions are three unconditional continues in the recursive walker, listPathsRecursively:

if (entry.name.startsWith(".")) continue;
if (entry.name === "node_modules") continue;
if (entry.isSymbolicLink()) continue;

• host.list_paths command params carry path, query, limit, includeFiles, includeDirectories — nothing to relax the above.
• browseHostDirectory applies the same two name rules, so the interactive path browser cannot reach them either. (It does follow symlinks, deliberately — single-level browsing has no loop risk.)
• Consumers that inherit the behavior: environments.paths (routes/environments.ts#L625), projects.paths (routes/projects.ts#L680), and files.listPaths (routes/files.ts#L292).
• host.read_file has no equivalent exclusion, which is why the read above succeeds.

Note the dotfile rule is much broader than the node_modules one. It hides .github/, .claude/, .bb/, .vscode/ and everything under them — directories users edit routinely — while node_modules at least matches most people's intent most of the time.

What you ruled out

• Not gitignore: nothing reads an ignore file; the names are literals in the walker. .github/workflows/ is committed and not ignored.
• Not the fuzzy ranker dropping it: raising limit and querying workflows directly still returns nothing under .github/. The AGENTS.md control proves the endpoint and environment are right.
• Not a permissions or symlink artifact: .github/workflows/ci.yml is a regular file and reads fine through host.read_file on the same host and root.
• Not a duplicate: searched open and closed for list_paths dotfiles, file search hidden files, node_modules exclusion, listPathsRecursively — no matches.
• Not plugin-specific: the repro above is entirely first-party.

Suggested priority and effort

Medium priority, small-to-medium effort. It silently makes a class of real project files unreachable from quick-open, and the failure is invisible — the search returns other results, so it reads as "no such file" rather than "this file is filtered".

Suggested shape: make the exclusions caller-configurable on host.list_paths rather than baked into the walker — for example includeHidden and includeNodeModules (or a general exclude list), defaulting to today's behavior so nothing changes for existing callers. That keeps quick-open's defaults sane while letting a file tree offer "show hidden files" and letting a plugin decide for itself. Note this is a wire change and would need a HOST_DAEMON_PROTOCOL_VERSION bump per AGENTS.md.

If the appetite is smaller, narrowing the dotfile rule alone — skipping .git/ rather than every dot-leading name — would fix the reported symptom without a protocol change.

Found in bb thread thr_nnk8m7d8gw while building a Monaco fileOpener plugin; see also #2026 and #2072 from the same work.

AGENT GENERATED: by Claude Opus 5

[SawyerHood]

Reproduction & root-cause report: https://get-bb.github.io/reports/issues/2093.html

• Verdict: REPRODUCED · root-cause confidence: high
• Root cause (short): The host daemon's shared recursive walker listPathsRecursively (apps/host-daemon/src/command-handlers/file-list.ts:143-145) unconditionally skips every dot-leading entry, node_modules and symlinks, with no host.list_paths/host.list_files parameter to relax it, so every server path-search route, quick-open, @-mentions and plugins inherit the rule while host.read_file serves the same files.
• Linked PR review: Include project dot paths in file listings #2103 → REQUEST CHANGES — Narrowing the skip list to .git/node_modules fixes the named symptom (my repro test passes) but the uncapped per-keystroke walker now descends .venv/.turbo/.next/.cache: measured listHostPaths(query 'config') on a Python repo went from 6-8ms to 629-1234ms and the project's own config.py was pushed o; Ship the Monaco editor as a builtin plugin #2127 → REQUEST CHANGES — Does not fix Path listing hides every dotfile and node_modules unconditionally, so file search cannot find .github/workflows/ci.yml #2093 (lists it as a known gap; Fixes # is blank) and must not close it. On its own: the tree RPC for host-kind files calls files.listPaths on dirname(file) with limit 10000 and the daemon walks the whole subtree before truncating, so 'Show in files' on ~/notes.md walks all of $HOME unb
• Proposed fix: Separate policy from primitive: add required includeHidden: boolean, excludeNames: string[] (and respectGitignore: boolean) to hostListFilesCommandSchema/hostListPathsCommandSchema, have the daemon walker take them as arguments (always refusing to descend .git) and bump HOST_DAEMON_PROTOCOL_VERSION 150->151; the server fills product defaults once (includeHidden true, excludeNames ['node_modules'], respectGitignore true) for workspace search routes and passes includeHidden:false from the two skill consumers whose read path denies dotfiles; expose includeHidden on files.listPaths/paths routes, S…
• Caveats: One real codex turn ("Reply only with ok.") was spent to get a thread/environment for the UI screenshots. Benchmarks used real local repos (~/podcast, ~/browser-use, ~/mcp-client, ~/bb) on this machine; absolute timings are machine-specific but the ratios are the point. The PR Ship the Monaco editor as a builtin plugin #2127 host-kind unbounded-walk finding is reasoned from code (walker has no cap) and not measured because the sandbox coul…

The report has copy-paste repro steps, screenshots where the bug is visual, code permalinks at the base commit, and repro artifacts. It was independently re-run by a second agent (see its Verification section).

AGENT GENERATED: by Claude Opus 5