[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

Start the headless server directly, without a reverse proxy:
```
t3 serve --host 127.0.0.1 --port 3773 /path/to/projects
```
Open and pair the web client at http://127.0.0.1:3773.
Open an existing project/thread.
Open the right panel, select Files, and wait until the project tree is visible.
Create a file outside T3 in the project root:
```
touch file-created-outside-t3.txt
```
Press F5 and wait for the app and Files panel to reload.
Confirm that file-created-outside-t3.txt is still absent.
Click Refresh workspace files in the Files panel.
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:

FileBrowserPanel passes entriesQuery.refresh to the Refresh workspace files button.
useProjectEntriesQuery.refresh only refreshes the client-side projects.listEntries query atom.
On the server, WorkspaceEntries.list() calls WorkspaceSearchIndex.list() without calling WorkspaceEntries.refresh() or WorkspaceSearchIndex.refresh() first.
The actual filesystem rescan exists in WorkspaceSearchIndex.refresh() as finder.scanFiles().
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:

initialize and list a workspace,
create a file externally after the index exists,
invoke the refresh path,
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.

Confirmed this on current main with a deterministic WebSocket regression. After projects.listEntries initializes the workspace index, external creates/moves/deletes remain stale on subsequent list calls, while the existing WorkspaceEntries.refresh(cwd) correctly rescans the filesystem.

The smallest boundary I found is a dedicated projects.refreshEntries command that runs that existing refresh server-side, then revalidates the normal listEntries query. Normal reads remain cached, and the same path works for web/desktop/mobile and remote environments.

I have a focused patch and regression coverage implementing that boundary. I'm opening it as a small PR for review, with F5/live invalidation intentionally left out of scope.

Same on t3 v0.0.33 (stable), Ubuntu 24.04.3, headless server + remote browser.

Two additions to the report: deletions go stale too, not just creations — two files deleted by an agent were still listed in the Files panel ~15 min later, which is worse than a missing entry since the tree shows paths that no longer exist and nothing looks wrong. And it's not only the tree: an open editor tab still rendered the first version of a file rewritten three times, while a terminal on the same host printed the current content. Same path, same filesystem, so it's client/server cache.

Workaround: read the file in a terminal. F5 and Refresh workspace files didn't help, matching the original report.

The files panel is practically unusable (especially when agent output produces deeplinks to the file explorer) -- Given that theres no way to force refresh the cache, i dont see a workaround to view remote files. Terminal works but im seeing stale images which is trickier.

recommend prioritizing this