[Bug]: Add-project folder picker serves a stale directory listing, folders created outside the app never appear#11476

openedSep 12, 2026byAAnay0305

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/web (the same code path is shared with apps/mobile through packages/client-runtime)

Steps to reproduce

  1. Open the command palette and start the "Local folder" add-project flow, browsing to some directory, for example ~/Desktop/Personal/.
  2. Close the palette.
  3. Create a new folder inside that directory outside T3 Code (file manager, mkdir, another app).
  4. Reopen the palette and browse to the same directory again.

Expected behavior

The listing reflects the directory on disk: the new folder appears when the picker is reopened.

Actual behavior

The listing is the cached one from the previous open. The new folder does not appear, no matter how many times the picker is closed and reopened, until roughly 5 minutes of not touching that directory have passed. There is also no manual refresh affordance in the picker to force it.

Impact

Minor bug or occasional failure

Version or commit

main @ c0ddfb3a8

Environment

Linux desktop app and web, reproduced against a local environment

Root cause

The browse listing comes from the filesystem.browse query atom family, which is wired with Atom.swr({ staleTime: 30_000, revalidateOnMount: true }) plus Atom.setIdleTTL(5 * 60_000) in packages/client-runtime/src/state/runtime.ts (createEnvironmentQueryAtomFamily).

Atom.swr only re-checks staleness inside its transform build function, which runs when the atom node is (re)built. The idle TTL keeps the node alive for 5 minutes after the palette closes, so reopening the picker resubscribes to a warm node and simply reads the cached value: the swr staleness check never runs, revalidateOnMount never fires, and no refetch happens. The listing is effectively frozen for the idle TTL window even though staleTime is 30 seconds.

Web (CommandPalette browse mode) and mobile (FolderBrowser in AddProjectScreen) both consume this atom family and both exhibit the staleness.

Workaround

Leave that directory unvisited for over 5 minutes so the idle TTL drops the atom node, or restart the client.

Notes

A minimal fix is ready on a branch (revalidate once when a picker mounts onto a warm cached atom, on web and mobile), happy to open a PR. The missing "new folder" affordance that makes this sting extra is already proposed in discussion #10353.

Reproduced on Linux web with isolated dev state at b5a226e49c. Command palette → Add project → Local folder → /tmp/t3-11476-repro/ showed existing. Closed the palette, ran mkdir /tmp/t3-11476-repro/created-externally, then reopened and browsed the same path: only existing appeared. Starting a fresh Add project flow gave the same stale result.

Before external creation: initial-listing.png

After external creation and reopen: stale-after-external-mkdir.png

Recording: fresh Local folder flow still serves the cached listing (0s: choose Local folder; 1s: enter the previously visited path; 2s: only existing is listed). Chromium, 1280×800, dark theme. No duplicate issue or matching fix PR found in the listings checked.

Fix in #23289. The regression test fails on the baseline and all 32 focused tests pass with the fix. A Linux web check on the final branch shows an externally created folder after reopening the picker. The PR includes recovered before/after recordings and lists unverified desktop, native mobile, platform, and connection-mode coverage.