Grouped project icon differs between settings and sidebar

[andybergon]

Update: local case resolved

After pulling the commit containing t3.json and the favicon into the Windows checkout, then fully closing and reopening T3 Code, the sidebar now shows the correct icon.

I can no longer reproduce the mismatch. I didn’t test pulling and restarting separately, so I can’t tell which step resolved it. The source-selection difference noted below remains, but this case no longer demonstrates an ongoing bug.

Original report

With the same repository grouped across two connected environments, project settings shows the automatic favicon while the desktop sidebar shows a generated monogram.

Settings selects the first connected group member, whereas the sidebar prefers the primary environment. Executing those selection expressions with two connected members reproduces the different choices.

Expected: the group’s settings preview and sidebar agree on its icon.

The selection mismatch exists in upstream commit 5ea6439816470288d3f2b6b43635fea41fbbb101. The reason the local checkout returns a fallback has not yet been established.

Related: #7464, closed unmerged. This report concerns the inconsistent group preview, without proposing cross-client caching or retry machinery.

[juliusmarminge]

Triage

Confirmed: grouped project settings and the sidebar pick different group members for the icon, so one surface can show the automatic favicon and the other a monogram.

What’s going on

The sidebar (and the project picker / command palette) builds groups through buildProjectGroups → buildSidebarProjectSnapshots, which prefers the primary environment member, then members[0]. That snapshot is what ProjectFavicon receives.

Project settings does not use that representative. ProjectSettingsPanel overwrites the snapshot identity with members[0], then re-selects the first member whose environment has a serverConfig (first connected checkout):

• apps/web/src/components/settings/ProjectSettingsPanel.tsx
• packages/client-runtime/src/state/projectGrouping.ts
• apps/web/src/sidebarProjectGrouping.ts

Other settings scope already prefers the primary among connected environments (SettingsScopeContext / selectScopedSettingsEnvironments). This panel is the outlier.

With two connected members, executing those two expressions yields different environmentId / cwd / faviconPath. ProjectFavicon then renders a resolved favicon on one surface and the monogram fallback on the other (fallback behavior from #11572).

The selection mismatch is present on current main, including 5ea6439816470288d3f2b6b43635fea41fbbb101. Why the local/primary checkout’s automatic favicon itself falls back is a separate per-checkout resolution question and is out of scope here, as reported.

Web and desktop share this UI. Mobile has no matching Project settings icon preview.

Related

• fix(clients): keep project icons consistent across environments #7464 (closed, unmerged) — broader shared cache / retry. Related, not a duplicate of this selection bug.
• fix(web): preserve checkout when opening project settings #11406 (open) — checkout-preservation change that also switches this panel to the sidebar representative. Broader than this issue; it would fix the mismatch if it lands.
• fix(web): use project monograms for automatic icon fallbacks #11572 — why the fallback is a monogram.
• fix(web): keep automatic project icons consistent #9535 / refactor(web): pass the project record to ProjectFavicon so icons cannot drift #10714 — title/prop drift, not group-member selection.
• [Bug]: Cropping Favicon #7416 / [Bug]: Android project filter omits recognized project favicons #7981 — different (cropping; Android filter).

No open duplicate. Not already fixed on main.

Suggested fix

Keep this issue open and align the settings preview with the sidebar snapshot (primary-preferred member). Smallest change: stop using “first connected” for the icon; reuse the snapshot identity. A file picker can still require a live checkout without driving the preview.

Do not revive #7464’s cache/retry machinery for this. If #11406 merges first, re-check before opening a separate PR.

Labels: bug, accepted, via-triage (remove needs-triage)