Repository navigation
Description
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
- Create a folder outside any existing Git repository.
- Add a PNG or JPEG image and a text file before opening the folder in T3 Code.
- Open the folder as a project and inspect the Files sidebar.
Expected behavior
The Files sidebar lists both the image and the text file.
Actual behavior
The text file appears, but the image is missing.
Impact
Minor bug or occasional failure
Version or commit
0.0.40-nightly.20260907.1359
Environment
Linux x64
Screenshots, recordings, or supporting files
ImagesNoGitRepo.png
ImagesGitRepo.png
Astra Description and Research
The underlying behavior was reproduced independently using FFF 0.9.4 with T3's path-index configuration:
{
basePath: cwd,
disableMmapCache: true,
disableContentIndexing: true,
aiMode: false,
enableFsRootScanning: true,
enableHomeDirScanning: true,
}After awaiting waitForIndexReady(), both mixedSearch("", { pageSize: 100 }) and fileSearch("", { pageSize: 100 }) omitted the images.
| State when FFF scans the folder | Result with FFF 0.9.4 |
|---|---|
| No Git repository | PNG, JPEG and .bin files missing |
| Git initialized before creating the files | Files included |
| Files created before Git initialization, then scanned | Files included |
| Files staged or committed | Files included |
For an index already opened without Git, running git init left the files absent in the immediate query. Calling scanFiles() and awaiting waitForIndexReady() restored them. The live-watcher behavior for files created after indexing wasn't independently tested.
The cause appears to be this explicit check in FFF 0.9.4's filesystem scanner:
if !is_git_repo && is_known_binary_extension(path) {
return ignore::WalkState::Continue;
}This drops files before they enter the index. T3's WorkspaceSearchIndex.list() uses mixedSearch, but switching to file-only search wouldn't resolve the issue because both search the same incomplete index.
The filtering is based on extensions. Plain text saved as text.png was also excluded, while .txt and .svg files were included. The extension list covers other formats such as PDFs, archives, fonts and databases, though those weren't individually tested.
Possible fix: upgrading FFF looks promising. Running the same standalone reproduction against published version 0.10.6 included all the test files, with and without Git.
That upgrade hasn't been verified inside T3. It would need regression coverage for listing images in non-Git projects and a check of the existing Electron .asar.unpacked loading patch, since FFF's package layout changed between these versions.
A temporary workaround is to initialize Git and rebuild the server-side index. Existing images don't need to be recreated.
The dependency reproduction and source investigation were performed with Codex assistance. No production fix or integrated browser/mobile test has been completed.
Activity
juliusmarminge commentedon Sep 8, 2026
Triage
Confirmed, not a duplicate. In a non-Git project root the Files sidebar omits images and other known-binary types while text files in the same folder appear. The same files show up after
git init. Distinct from #8665 / PR #8670 (non-Git dot-entries), #7528 (setup.sh/setup.ps1), and #6452 (stale refresh).Cause
The Files tree is
projects.listEntries→WorkspaceEntries.list→WorkspaceSearchIndex.list→ FFFmixedSearchon the path index (@ff-labs/[email protected]). The sidebar does not filter binaries itself.FFF 0.9.4’s scanner skips known binary extensions when the root is not a Git repo:
Those files never enter the index, so they also miss
@/ file-picker search andimageOnlyqueries. The skip is extension-based (PNG/JPEG/GIF/WebP, PDF, archives, fonts, DBs, media,.bin, …)..svgand.txtare not on that list, which matches the report. The check is gone on current FFF main.Next step
Upgrade
@ff-labs/fff-node(standalone 0.10.6 included the files with and without Git). Re-apply/adaptpatches/@[email protected](Electron.asar.unpackedloader) and recheck desktop native-bin staging inscripts/build-desktop-artifact.ts. Add aWorkspaceEntries.listregression for images (and ideally.bin/.pdf) in a non-Git temp dir. Do not wait on #8670.Workaround:
git initin the project root, then rebuild the server-side index (scanFiles/ restart). Existing images do not need to be recreated.juliusmarminge commentedon Sep 8, 2026
Triage
Reproduced in the attached screenshots and confirmed in the current tree. This is a real server-side index bug, not a Files-sidebar rendering issue.
projects.listEntriesis backed by@ff-labs/[email protected](WorkspaceSearchIndex.list→FileFinder.mixedSearch). T3’s finder options match the standalone FFF repro in the issue body. In FFF 0.9.4 (7d7910b), the filesystem walker skips known binary extensions when the folder is not a Git repo:That list includes
png/jpeg/jpgplus PDFs, archives, fonts, video,.bin, etc..svgand plain text are not in the list, which matches “text shows, images don’t.” The files never enter the index, sofileSearch/imageOnlysearch are also empty. Switching the T3 query API cannot fix it.Git repos work because that skip is gated on
!is_git_repo.git initafter the index is already open does not immediately restore entries; a rescan (scanFiles+waitForIndexReady, or the Files refresh path) is required.Not a duplicate
Same area, different filter as #8665 (dot-entries invisible in non-git Files). Open PRs #8670 and #8402 do not address this.
Suggested fix
Upgrade
@ff-labs/fff-nodeto 0.10.6+. FFFv0.10.6no longer drops those files from the non-git walk (standalone repro in the issue). That bump is not free:patches/@[email protected](Electron.asar.unpackedresolve)…/fff-node/dist/src/index.js— 0.10.6 shipsdist/index.js.png/.txt(and one other binary ext) must appear inWorkspaceSearchIndex.list()Workaround: initialize Git in the project root, then refresh the Files panel so the server rebuilds the index.
Labels: keep
bug; addaccepted,via-triage; removeneeds-triage.