[Bug]: Dot-entries are invisible in the Files panel of a project that is not a git repository

[!NOTE]
🤖 Claude Opus 5 writing on behalf of the reporter

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

Minimal repro, deliberately outside any git repository (git rev-parse --show-toplevel → fatal: not a git repository):

dotfile-repro/
├── .hidden-dir/
│   └── inside.txt
├── .hidden-file.txt
├── visible-dir/
│   └── inside.txt
└── visible.txt

1. Create that tree. Do not run git init. There is no .gitignore anywhere above it.
2. Add the folder as a project in T3 Code.
3. Open the Files panel.

Expected behavior

All four entries are listed. Nothing here is tracked, ignored, or excluded by any rule — there is no repository and no ignore file to consult.

Actual behavior

Only visible.txt and visible-dir/ appear. .hidden-file.txt and .hidden-dir/ are absent, and there is no setting anywhere that reveals them. The same happens in my real project, whose root is likewise not a git repository: several plain, unignored dot-directories there are invisible in the Files panel in exactly the same way.

In the real project I also saw the dot-entries render in the tree for roughly a second and then disappear, which suggests a second pass removes them rather than the first listing never including them. I could not reproduce that timing reliably in the minimal repro above, so treat it as an observation, not a repro step.

Why this is not a duplicate of #7558 / discussion #7546

#7558 was closed not planned and handed to Ideas #7546, whose title states "the filter is .gitignore, not dotfiles", and the closing comment says "the evidence already in this discussion shows that tracked dotfiles are already visible".

That framing does not cover this case. In a directory that is not a repository, no file is tracked, so "tracked dotfiles are visible" cannot explain why visible.txt shows and .hidden-file.txt does not — both have identical status: none. Something is filtering on the leading dot, independently of git.

The same closing comment explicitly reserves this: "A file that is neither ignored nor visible would be a separate bug and is not dismissed by this policy closure." Filing it as instructed.

Additional evidence

1. The RPC that feeds the Files panel has no flag for this.

projects.listEntries (observed in server.trace.ndjson with rpc.aggregate: "workspace") accepts exactly one field:

export const ProjectListEntriesInput = Schema.Struct({
  cwd: TrimmedNonEmptyString,
});

export const ProjectListEntriesResult = Schema.Struct({
  entries: Schema.Array(ProjectEntry),
  truncated: Schema.Boolean,
});

No includeHidden, no includeIgnored. So no client-side setting can fix this — the contract itself has to change. That likely also explains why #5951 and #8047 were both closed unmerged.

2. git check-ignore cannot succeed here, and the driver treats that as a hard error.

GitVcsDriver.filterIgnoredPaths tolerates only exit codes 0 and 1:

if (result.exitCode !== 0 && result.exitCode !== 1) {
  return yield* new VcsProcessExitError({
    operation: "GitVcsDriver.filterIgnoredPaths",
    command: "git check-ignore",
    cwd,
    exitCode: result.exitCode,
    detail: result.stderr.trim() || "git check-ignore failed",
  });
}

Outside a repository git check-ignore exits 128, not 0 or 1:

$ cd "$(mktemp -d)"   # any directory with no repository above it
$ printf 'a\0.b\0' | git check-ignore -z --stdin
fatal: not a git repository (or any of the parent directories): .git
$ echo $?
128

So on a non-repo project root this path raises VcsProcessExitError instead of returning the paths unfiltered. Whether the Files panel is the caller that swallows it, I could not confirm from the packaged bundle — but the failure codes in the contract (search_index_create_failed, search_index_scan_timed_out) suggest the entry list is index-backed and has a second stage that could drop entries after the first render.

I have not verified whether a tracked dotfile inside a real repository is visible; this report is specifically about the non-repository case, where the gitignore explanation cannot apply.

Impact

Major degradation or frequent failure

Version or commit

0.0.36

Environment

macOS 26.6.2, arm64 (Darwin 25.6.0), T3 Code (Alpha) 0.0.36, Node v24.20.0, Claude provider 2.1.251

Logs or stack traces

# projects.listEntries returns Success — the entries simply do not contain the dot-entries
{"type":"effect-span","name":"ws.rpc.projects.listEntries",
 "attributes":{"rpc.transport":"websocket","rpc.system":"effect-rpc",
 "rpc.method":"projects.listEntries","rpc.aggregate":"workspace"},
 "durationMs":73.811875,"exit":{"_tag":"Success"}}

Workaround

None inside the Files panel or the @ mention picker. The built-in terminal (⌘J) is the only way to reach these files from within T3 Code.

Partial, and on a different surface: the add-project path autocomplete does reveal dot-directories, because it applies showHidden = endsWithSeparator || prefix.startsWith(".") — typing a leading . or a trailing separator lists them. Nothing equivalent exists for the Files panel.

Start at the projects.listEntries entry point and inspect ProjectListEntriesInput/Result alongside GitVcsDriver.filterIgnoredPaths. Reproduce the four-entry tree outside a git repository and check how the git check-ignore exit code is handled. Done means dot-files and dot-directories remain visible in the Files panel without a fatal VCS error.