Skip to content

vscode: builder changed-file rows render grey instead of SCM colors #799

Description

@amrmelsayed

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.

Activity

  1. self-assigned this
    on May 21, 2026
  2. amrmelsayed commented on May 26, 2026

    @amrmelsayed
    CollaboratorAuthor

    On it! Working on a fix now.

  3. added a commit that references this issue on May 26, 2026
    0301b7f
  4. added a commit that references this issue on May 26, 2026
    b672595
  5. amrmelsayed commented on May 29, 2026

    @amrmelsayed
    CollaboratorAuthor

    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:

    1. The custom scheme isn't reaching the FileDecorationProvider — VSCode might be matching some other decorator first.
    2. The Codev decorator registration may have regressed or be racing against the built-in Git decorator on activation order.
    3. 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).
    4. 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.

  6. amrmelsayed commented on May 30, 2026

    @amrmelsayed
    CollaboratorAuthor

    On it! Working on this with the PIR protocol (plan + dev-approval gates before PR).

  7. added 8 commits that reference this issue on May 30, 2026
  8. added 5 commits that reference this issue on May 30, 2026
    487fd00
    ae49796
    65bcbb2
    5f078a7
    3e00f9e
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area/vscodeArea: VS Code extensionbugSomething isn't working

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions