[Bug]: Files panel silently truncates large workspaces at 25,000 entries

[SnaiCrys]

Before submitting

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

Area

apps/server

Steps to reproduce

1. Create a workspace containing more than 25,000 files:

mkdir t3-files-limit-repro
cd t3-files-limit-repro
git init
mkdir files

for i in $(seq -w 1 30000); do
  printf 'file %s\n' "$i" > "files/file-$i.txt"
done

2. Add the directory as a T3 Code project.
3. Open the Files panel.
4. Inspect the displayed file tree.

Expected behavior

Every file and directory should remain accessible from the Files panel, regardless of the total workspace size.

Actual behavior

The Files panel silently omits part of the workspace.

The server limits the workspace index to 25,000 entries:

const WORKSPACE_INDEX_MAX_ENTRIES = 25e3;
const WORKSPACE_INDEX_PAGE_SIZE = 25002;

The result is sliced again when the file list is constructed:

const entries = sortedEntries.slice(0, WORKSPACE_INDEX_MAX_ENTRIES);

The request completes successfully, so the Files panel displays the truncated result without an error or warning.

The Files tree should enumerate directories lazily when they are expanded. The bounded workspace index can remain in use for search and the @ file picker.

Impact

Major degradation or frequent failure

Version or commit

T3 Code Nightly 0.0.29-nightly.20260727.918

Environment

Windows 11 T3 Code Desktop Nightly 0.0.29-nightly.20260727.918 Electron 41.5.0 Workspace hosted in WSL2 Git 2.43.0

Logs or stack traces

No failure is emitted while loading the Files panel.

The following operations complete successfully:

ws.rpc.projects.listEntries
WorkspaceEntries.list
WorkspaceEntries.normalizeWorkspaceRoot

Screenshots, recordings, or supporting files

No response

Workaround

No response