Skip to content

[Bug]: Images and other binary file types are missing from Files sidebar in non-Git projects #10628

Closed

Description

@dylan1020

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 folder outside any existing Git repository.
  2. Add a PNG or JPEG image and a text file before opening the folder in T3 Code.
  3. 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

  1. added
    bugSomething is broken or behaving incorrectly.
    needs-triageIssue needs maintainer review and initial categorization.
    on Sep 8, 2026
  2. juliusmarminge commented on Sep 8, 2026

    @juliusmarminge
    Member

    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 → FFF mixedSearch on 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:

    if !is_git_repo && is_known_binary_extension(path) {
        return ignore::WalkState::Continue;
    }

    Those files never enter the index, so they also miss @ / file-picker search and imageOnly queries. The skip is extension-based (PNG/JPEG/GIF/WebP, PDF, archives, fonts, DBs, media, .bin, …). .svg and .txt are 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/adapt patches/@[email protected] (Electron .asar.unpacked loader) and recheck desktop native-bin staging in scripts/build-desktop-artifact.ts. Add a WorkspaceEntries.list regression for images (and ideally .bin/.pdf) in a non-Git temp dir. Do not wait on #8670.

    Workaround: git init in the project root, then rebuild the server-side index (scanFiles / restart). Existing images do not need to be recreated.

  3. added
    via-triageFiled through npx t3 triage
    acceptedfeature request accepted
    and removed
    needs-triageIssue needs maintainer review and initial categorization.
    on Sep 8, 2026
  4. juliusmarminge commented on Sep 8, 2026

    @juliusmarminge
    Member

    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.listEntries is 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:

    if !is_git_repo && is_known_binary_extension(path) {
        return ignore::WalkState::Continue;
    }

    That list includes png / jpeg / jpg plus PDFs, archives, fonts, video, .bin, etc. .svg and plain text are not in the list, which matches “text shows, images don’t.” The files never enter the index, so fileSearch / imageOnly search are also empty. Switching the T3 query API cannot fix it.

    Git repos work because that skip is gated on !is_git_repo. git init after 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-node to 0.10.6+. FFF v0.10.6 no longer drops those files from the non-git walk (standalone repro in the issue). That bump is not free:

    • rewrite / re-pin patches/@[email protected] (Electron .asar.unpacked resolve)
    • update desktop probe path …/fff-node/dist/src/index.js — 0.10.6 ships dist/index.js
    • add a regression: non-git temp dir with .png / .txt (and one other binary ext) must appear in WorkspaceSearchIndex.list()

    Workaround: initialize Git in the project root, then refresh the Files panel so the server rebuilds the index.

    Labels: keep bug; add accepted, via-triage; remove needs-triage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    acceptedfeature request acceptedbugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions