Web project picker is empty until a search is entered

[ndj888]

Description

In opencode web, opening Add Project initially shows "No folders found" even though the startup/home directory contains folders.

The empty filter is sent to /find/file as query=, which returns an empty list. Entering a path makes folders appear, so project selection is not discoverable on first open.

Plugins

Reproduces without plugins.

OpenCode version

1.18.2

Steps to reproduce

1. Run opencode web --hostname 0.0.0.0 --port 8088.
2. Open the Web UI.
3. Click Add Project.
4. Observe that the picker says no folders were found.

Expected: list folders in the startup/home directory.
Actual: empty picker until text is entered.

Screenshot and/or share link

Network request: GET /find/file?directory=<home>&query=&type=directory&limit=50 returns [].

Operating System

macOS

Terminal

iTerm2

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• [BUG] opencode web can not open projects #37005: Same symptom — opencode web Add Project picker returns no results when query is empty (find file query="" results=0), making project selection fail on first open.

[lilxckd-cloud]

Independent reproduction on 1.18.9 (arm64, Jetson / Ubuntu 20.04). Confirming this, and I think I can add the missing piece of why the empty query returns nothing.

The empty filter takes a different code path from a typed one

packages/app/src/components/directory-picker-domain.ts, in createDirectorySearch:

const pathInput = raw.startsWith("~") || !!pickerRoot(raw) || raw.includes("/")
if (!pathInput) {
  const results = await args.sdk.api.file
    .find({ location: { directory: input.directory }, query, type: "directory", limit: 50 })
  ...
}
// inputs containing "/" fall through to match() -> directories() -> file.list()

An empty filter is not pathInput, so it goes to file.find. Anything containing / goes to file.list. That asymmetry is the whole bug: file.list works fine, file.find does not, in exactly the directory the picker opens on.

Why file.find returns empty there

file.find is backed by the FFF index, which refuses to run in a home directory or the filesystem root — the two places the picker defaults to (dialog-select-directory-v2.tsx uses sync.data.path.home || sync.data.path.directory). The server logs it plainly:

level=WARN message="failed to initialize fff" error="Failed to init file picker:
Can not run certain FFF features in a file system root or home directories.
Consider smaller per-project directories."

Reproducible straight from curl — same server, same flags, only the directory differs:

$ curl -s '.../find/file?query=&dirs=true&limit=50&directory=%2Fhome%2Fipzero'
[]

$ curl -s '.../find/file?query=&dirs=true&limit=50&directory=%2Fmnt%2Fdata'
["chat/opencode.json","jetson-containers/...","..."]

So it is not that the endpoint is broken generally — it is empty specifically under $HOME, which is where the picker starts. This also explains the workaround people keep rediscovering (typing ~/projects or an absolute path): any input with a / switches to file.list and works.

Related: #39655 reports the same symptom and includes the identical FFF log line; #39434 attributes it to a missing path param, which I could not confirm here — on 1.18.9 the request is well-formed and returns 200 with an empty array rather than a 400.

Fix

Listing the directory when the filter is empty is enough — match(directory, "", 50) already handles the empty-query case and routes through file.list. A non-empty filter keeps using file.find as before.

Verified on the reproduction: Add Project now opens showing /mnt/data/chat under Recent projects plus the home directory's folders, instead of "No folders found". Added two unit tests to directory-picker-domain.test.ts — one asserting the empty filter lists via file.list and never calls file.find, one asserting a non-empty filter still fuzzy-finds. The first fails on unmodified dev and passes with the change; packages/app unit tests go 692 -> 694 passing with no new failures.

Glad to open a PR if that's wanted — I see #37612 is already open against this issue.