[Feature]: Setting to show gitignored files in the Files panel (the filter is .gitignore, not dotfiles)

[TriptoAfsin]

The ask

A T3-owned setting to show gitignored files in the Files panel and the @ picker. Off by default — this is not a request to change the default.

What is actually filtered (it is not dotfiles)

I assumed this was a dotfile filter or a deliberate secrets guard. It is neither. I probed the workspace index directly with the same FileFinder options the server uses in WorkspaceSearchIndex.createFinder, against this repo:

entry	in index?	why
package.json	visible	tracked
.gitignore	visible	dotfile, tracked
.gitattributes	visible	dotfile, tracked
.env.example	visible	dotfile, tracked (!.env.example in .gitignore)
.github/workflows/release.yml	visible	inside a dot-directory, tracked
.env	hidden	matches .gitignore:37 .env*
node_modules	hidden	gitignored

14,384 of the 17,652 entries the tree listing returns are dot-prefixed. .env.example and .env are the cleanest pair: same directory, same dot prefix, same .env stem — the tracked one is visible, the ignored one is not. The filter is .gitignore, nothing else.

So the current behavior is surprising in a specific way: users read the missing .env as "dotfiles are hidden" and go looking for a hidden-files toggle that would not help, because .gitignore is doing the work.

It is not a security boundary today

Worth stating plainly, because "it might be deliberate for secrets" is the natural assumption and it does not hold:

• WorkspaceFileSystem.readFile has no ignore check at all — only a realpath-based workspace-escape guard. Hand it .env over RPC and it returns the contents. Only discovery is blocked, not reading.
• Any agent in the integrated terminal can cat .env right now.

So the setting would not open a new hole. It would make an already-reachable file discoverable in the UI.

Prior art

#1654 asked for this via the Claude CLI's respectGitignore, and @juliusmarminge closed it with:

respectGitignore is a Claude CLI setting and does not govern T3 Code's workspace index; T3 intentionally excludes ignored paths from @ search. We are not going to make provider config silently change the app-wide file index.

That reads to me as a rejection of provider config silently reaching into the app-wide index, which I agree with, rather than of the capability itself. This is the other shape: an explicit T3 setting the user turns on, owned by T3, affecting nothing else.

The real use cases are the ones from that thread and mine: intentionally-ignored agent instruction folders (.agent/, .claude/ variants), local scratch notes, and .env files people genuinely want to read and edit in the app they are already working in.

The constraint (this is the interesting part)

The index cannot be asked to include ignored files. @ff-labs/fff-node@0.9.4's InitOptions exposes basePath, frecencyDbPath, historyDbPath, disableMmapCache, disableContentIndexing, disableWatch, aiMode, logFilePath, logLevel, the three cacheBudget* caps, enableFsRootScanning, and enableHomeDirScanning. There is no includeIgnored / noIgnore / hidden flag. I confirmed at runtime too — glob("**/.env"), glob(".env") and glob("node_modules/*") all return 0 matched, so ignored paths are absent from the index itself, not just filtered on the way out.

That leaves two routes:

A. Upstream flag in fff, then a T3 setting. Ask dmtrKovalenko/fff for an includeIgnored init option, then build a second index variant behind the setting. Cleanest end state, keeps one code path, but gated on an external maintainer and adds a third index variant next to paths and content.

B. Lazy readdir listing behind the setting. WorkspaceEntries.browse already does exactly this — a per-directory NodeFSP.readdir with an existing showHidden notion for the project picker. The Files panel could expand directories on demand through that path when the setting is on. No upstream dependency, and it dodges the obvious performance trap: list() today pushes a flat listing of up to 25,000 entries over the websocket (see #4640), and an unignored flat listing of any real repo is node_modules — six figures of entries. Lazy expansion never materializes that. The cost is a genuinely different data path for the tree, which is an architecture call for you, not for me.

Both leave @ search on the current index, since fuzzy search over an unignored workspace is a separate and much worse problem.

Happy to build it

I have the repro and the probe harness set up. If you tell me which route you want — or that you want it scoped to the Files panel only, or dropped entirely — I will implement it. I did not send a PR because option B changes how the Files panel gets its data, and that is your call to make rather than mine.

---

Investigated on Windows 11, desktop 0.0.33, main @ f2d5fc91e.

Model: Claude Opus 5 (1M context)
Harness: Claude Code

[vgreg]

I second that! This is crucial for my workflow; I mostly work on data science projects, and my output is reports or papers in PDF. These should be gitignored, just like you would gitignore a compiled binary program. Still, I want to see it right away, and having to switch to a different app to connect to my remote server and get the file breaks my workflow.