Repository navigation
vscode: builder changed-file rows render grey instead of SCM colors #799
Copy link
Copy link
Labels
area/vscodeArea: VS Code extensionArea: VS Code extensionbugSomething isn't workingSomething isn't working
Description
Activity
- addedbugSomething isn't workingSomething isn't workingarea/vscodeArea: VS Code extensionArea: VS Code extension
on May 21, 2026 On it! Working on a fix now.
- added a commit that references this issue
on May 26, 2026 - added a commit that references this issue
on May 26, 2026 Reopening — bug not actually fixed. Architect confirmed via fresh screenshot today (2026-05-29) that builder file rows are still rendering in flat grey rather than the expected SCM colors (Added green, Modified yellow, Deleted red).
The 3.1.4 fix (custom
codev-builder-diff:URI scheme so the built-in Git decorator skips the rows) appears to be in place in the bundled extension code, but the user-visible behavior is unchanged. Possible root causes to investigate:- The custom scheme isn't reaching the FileDecorationProvider — VSCode might be matching some other decorator first.
- The Codev decorator registration may have regressed or be racing against the built-in Git decorator on activation order.
- The change shipped but the bundled .vsix actually published to Marketplace may not be running the fix (Marketplace stale, user install stale, or builds differ from source).
- Theme-specific: the user's theme tokens may resolve the SCM colors to something visually indistinguishable from the default foreground.
Removing the corresponding entry from the unreleased vscode CHANGELOG until this is genuinely resolved. Bumping back to needs-investigation.
On it! Working on this with the PIR protocol (plan + dev-approval gates before PR).
- added 8 commits that reference this issue
on May 30, 2026 - added 5 commits that reference this issue
on May 30, 2026
Metadata
Metadata
Assignees
Labels
area/vscodeArea: VS Code extensionArea: VS Code extensionbugSomething isn't workingSomething isn't working
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.