Symptoms
In the Builders view (both list mode and tree mode), changed-file rows render with grey filenames regardless of status. The A / M / D status badges still appear on the right, but the label color does not — Added isn't green, Modified isn't yellow, Deleted isn't red. Reproduces against a freshly spawned builder worktree.
Cause
BuilderFileTreeItem sets resourceUri = vscode.Uri.file(path.join(worktreePath, rel)) — a file: URI pointing into .builders/<id>/…, which is gitignored in both the codev repo and (typically) any downstream repo using codev.
VSCode's IDecorationService is global: every registered FileDecorationProvider is queried for every file: URI rendered anywhere in the editor, including in custom TreeViews. So two providers fire for each row:
| Provider |
Badge |
Color |
| Built-in Git (treats path as gitignored) |
(none) |
gitDecoration.ignoredResourceForeground (grey) |
BuilderFileDecorationProvider (ours) |
A / M / D / … |
gitDecoration.addedResourceForeground / … |
In the merge, our badge wins (Git contributes none for ignored), but Git's color wins for the label tint — so you get our badge text rendered in Git's grey ignored color.
The interaction is sensitive to whether VSCode detects each .builders/<id>/ as its own git repository (controlled by git.repositoryScanMaxDepth / git.repositoryScanIgnoredFolders and worktree timing). When the worktree IS detected as its own repo, Git decorates by that repo's status and colors happen to agree with ours; when it isn't, the workspace repo's "ignored" view wins and everything goes grey. Tower restarts and fresh-spawn timing are enough to flip this.
Diagnostic
Hover a grey row. If the tooltip reads e.g. Modified · apps/web/src/components/settings-modal.tsx, our provider IS firing — the issue is purely the color merge losing to the Git decorator. If the tooltip is missing or generic, the lookup is broken and the diagnosis is different.
Proposed fix
Switch BuilderFileTreeItem.resourceUri from vscode.Uri.file(...) to a custom scheme, e.g. vscode.Uri.from({ scheme: 'codev-builder-diff', path: '/' + path.join(worktreePath, rel) }). The built-in Git decorator only acts on scheme === 'file', so it never fires on these rows — leaving our SCM colors uncontested. The native file-type icon still resolves because IFileIconTheme keys off basename/extension, not scheme.
Touch points:
packages/vscode/src/views/builder-file-tree-item.ts — change the resourceUri constructor.
packages/vscode/src/views/builder-diff-cache.ts — decorationFor(uri) and syncDecorations look up by uri.fsPath; verify fsPath is stable across the custom scheme (it is — fsPath is scheme-independent in practice) or switch keying to uri.toString().
packages/vscode/src/views/builder-file-decoration.ts — no change; it receives whatever URI the tree item carries.
Risks: any extension or core command that filters resourceUri.scheme === 'file' (e.g. some third-party "reveal in finder" implementations) will skip our rows. Built-in commands revealFileInOS, copyFilePath, etc. accept the fsPath regardless, so the right-click menu remains intact.
Related
7b06bf0d feat(vscode): SCM-style decorations for builder changed-file rows — introduced the current resourceUri = file: shape.
df75e1bf feat(vscode): toggle changed-files view between list and tree (SCM-style) — added tree mode; same BuilderFileTreeItem leaf shape, so this issue applies in both modes.
Symptoms
In the Builders view (both list mode and tree mode), changed-file rows render with grey filenames regardless of status. The
A/M/Dstatus badges still appear on the right, but the label color does not — Added isn't green, Modified isn't yellow, Deleted isn't red. Reproduces against a freshly spawned builder worktree.Cause
BuilderFileTreeItemsetsresourceUri = vscode.Uri.file(path.join(worktreePath, rel))— afile:URI pointing into.builders/<id>/…, which is gitignored in both the codev repo and (typically) any downstream repo using codev.VSCode's
IDecorationServiceis global: every registeredFileDecorationProvideris queried for everyfile:URI rendered anywhere in the editor, including in custom TreeViews. So two providers fire for each row:gitDecoration.ignoredResourceForeground(grey)BuilderFileDecorationProvider(ours)A/M/D/ …gitDecoration.addedResourceForeground/ …In the merge, our badge wins (Git contributes none for ignored), but Git's color wins for the label tint — so you get our badge text rendered in Git's grey ignored color.
The interaction is sensitive to whether VSCode detects each
.builders/<id>/as its own git repository (controlled bygit.repositoryScanMaxDepth/git.repositoryScanIgnoredFoldersand worktree timing). When the worktree IS detected as its own repo, Git decorates by that repo's status and colors happen to agree with ours; when it isn't, the workspace repo's "ignored" view wins and everything goes grey. Tower restarts and fresh-spawn timing are enough to flip this.Diagnostic
Hover a grey row. If the tooltip reads e.g.
Modified · apps/web/src/components/settings-modal.tsx, our provider IS firing — the issue is purely the color merge losing to the Git decorator. If the tooltip is missing or generic, the lookup is broken and the diagnosis is different.Proposed fix
Switch
BuilderFileTreeItem.resourceUrifromvscode.Uri.file(...)to a custom scheme, e.g.vscode.Uri.from({ scheme: 'codev-builder-diff', path: '/' + path.join(worktreePath, rel) }). The built-in Git decorator only acts onscheme === 'file', so it never fires on these rows — leaving our SCM colors uncontested. The native file-type icon still resolves becauseIFileIconThemekeys off basename/extension, not scheme.Touch points:
packages/vscode/src/views/builder-file-tree-item.ts— change theresourceUriconstructor.packages/vscode/src/views/builder-diff-cache.ts—decorationFor(uri)andsyncDecorationslook up byuri.fsPath; verifyfsPathis stable across the custom scheme (it is — fsPath is scheme-independent in practice) or switch keying touri.toString().packages/vscode/src/views/builder-file-decoration.ts— no change; it receives whatever URI the tree item carries.Risks: any extension or core command that filters
resourceUri.scheme === 'file'(e.g. some third-party "reveal in finder" implementations) will skip our rows. Built-in commandsrevealFileInOS,copyFilePath, etc. accept the fsPath regardless, so the right-click menu remains intact.Related
7b06bf0d feat(vscode): SCM-style decorations for builder changed-file rows— introduced the currentresourceUri = file:shape.df75e1bf feat(vscode): toggle changed-files view between list and tree (SCM-style)— added tree mode; sameBuilderFileTreeItemleaf shape, so this issue applies in both modes.