[Bug]: Files panel stays stale after external file creation, F5, and Refresh files

Before submitting

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

Related but not a duplicate: #791 covered newly created files missing from the @ picker and is already closed. This report is specifically about the Files surface in the right panel, including its explicit refresh button.

Area

apps/web and apps/server

Steps to reproduce

1. Start the headless server directly, without a reverse proxy:

   t3 serve --host 127.0.0.1 --port 3773 /path/to/projects
   

2. Open and pair the web client at http://127.0.0.1:3773.

3. Open an existing project/thread.

4. Open the right panel, select Files, and wait until the project tree is visible.

5. Create a file outside T3 in the project root:

   touch file-created-outside-t3.txt
   

6. Press F5 and wait for the app and Files panel to reload.

7. Confirm that file-created-outside-t3.txt is still absent.

8. Click Refresh workspace files in the Files panel.

9. Confirm that the file is still absent.

I reproduced this both through a same-origin reverse proxy and, importantly, directly against http://127.0.0.1:3773. The direct reproduction rules out the reverse proxy as the cause.

Expected behavior

Files created, renamed, moved, or deleted outside T3 should be reflected in the Files panel automatically. At minimum, pressing F5 or clicking Refresh workspace files should trigger a real filesystem rescan and show the current project contents.

Actual behavior

The Files panel keeps showing the old project tree. Neither F5 nor Refresh workspace files makes the externally created file appear. The refresh action completes without an error, but it returns the same stale entries.

This makes the panel unreliable when files are created by another editor, terminal command, build tool, Git operation, or another agent process.

Impact

Major degradation or frequent failure

Version or commit

t3 v0.0.34-nightly.20260812.1079

The same stale-data path is also present on the current main branch at the time of filing.

Environment

• Ubuntu 24.04, x86_64
• Node.js v26.5.1
• T3 headless web client in Chromium
• Direct connection to 127.0.0.1:3773
• Reproduced with an existing Git project

Logs or stack traces

No relevant error is emitted. The WebSocket remains connected, the existing tree loads successfully, and the refresh request completes. The returned file list is simply stale.

Technical investigation

The current implementation appears to explain the behavior:

1. FileBrowserPanel passes entriesQuery.refresh to the Refresh workspace files button.
2. useProjectEntriesQuery.refresh only refreshes the client-side projects.listEntries query atom.
3. On the server, WorkspaceEntries.list() calls WorkspaceSearchIndex.list() without calling WorkspaceEntries.refresh() or WorkspaceSearchIndex.refresh() first.
4. The actual filesystem rescan exists in WorkspaceSearchIndex.refresh() as finder.scanFiles().
5. The cached workspace index has a 15-minute idle TTL, so a browser reload can reconnect to the same stale server-side index.

This also explains why the bug is intermittent: T3-controlled writes and some orchestration/checkpoint paths call WorkspaceEntries.refresh(cwd), while external filesystem changes do not reliably invalidate the index.

Suggested fix

Make the explicit Files-panel refresh perform a server-side index refresh before reloading entries. For example:

• add a dedicated projects.refreshEntries RPC that calls WorkspaceEntries.refresh(cwd) and then re-fetches projects.listEntries, or
• make an explicitly forced projects.listEntries request rescan before listing.

For truly live updates, a debounced filesystem watcher could invalidate or refresh the path index when files change outside T3.

A regression test could:

1. initialize and list a workspace,
2. create a file externally after the index exists,
3. invoke the refresh path,
4. assert that the new file is returned.

Workaround

Restarting T3 or otherwise forcing the server-side workspace index to be rebuilt can update the tree, but there is no reliable in-app workaround. F5 and the visible refresh button currently do not perform the required rescan.

Start with FileBrowserPanel and useProjectEntriesQuery.refresh to trace the Files-panel refresh action, then inspect WorkspaceEntries.list and WorkspaceSearchIndex.refresh. Reproduce the stale index with an externally created file and run or add the suggested regression test. Done means the refresh path rescans the workspace and returns the new file in the Files panel.