[BUG]: Desktop project avatars flicker to path fallback before custom metadata hydrates #30172

Bug Description

OpenCode Desktop can briefly render sidebar project avatars from the project path fallback instead of the user's persisted custom project name/icon after the webview is reloaded or restored.

In my environment, I have open projects with custom names/icons. After using the macOS app menu OpenCode > Reload Webview, the sidebar initially restores the projects from persisted state, but the project entries are rendered before their custom project metadata has hydrated.

For example, a project at ~/Downloads/12-12 renamed to YOLO briefly renders with avatar fallback 1 from 12-12. As soon as I hover the project icon, it changes to Y because the child workspace store gets hydrated and the custom project metadata becomes available.

This also happens after hiding OpenCode Desktop with Cmd+H for a while and reopening it. Sometimes the correction happens without hover, depending on hydration timing.

Steps to Reproduce

1. Open OpenCode Desktop on macOS.
2. Open a project whose directory basename starts with a different character than the custom project name, e.g. ~/Downloads/12-12.
3. Rename the project in the sidebar to a custom name, e.g. YOLO, and optionally set a custom color/icon.
4. Use the macOS app menu:

OpenCode > Reload Webview

5. Observe the sidebar immediately after the webview reloads.
6. Move the cursor over the project icon.

Expected Behavior

OpenCode Desktop should render the sidebar project avatar/name from the user's last persisted custom project metadata immediately after reload/restore.

There should be no visible intermediate frame where a renamed project falls back to getFilename(project.worktree) and shows the wrong avatar letter.

Actual Behavior

The sidebar first renders the restored project entries as path-only shells. The avatar fallback is computed from the directory basename.

For ~/Downloads/12-12, the avatar initially shows:

1

After hover or after async hydration completes, the same avatar changes to the custom-name fallback:

Y

This makes the sidebar flicker and makes the restored project identity look inconsistent.

Technical Analysis

In the packaged Desktop renderer for version 1.15.13, the open project list is persisted globally under the server store. The restored project entries only contain the worktree and expansion state:

{
  "projects": {
    "local": [
      { "worktree": "/Users/.../Downloads/12-12", "expanded": true },
      { "worktree": "/", "expanded": true }
    ]
  }
}

The user's custom project metadata is stored separately per workspace, for example:

{
  "workspace:project": {
    "value": {
      "name": "YOLO",
      "icon": { "color": "purple" },
      "commands": {}
    }
  }
}

The avatar fallback uses the project name if available, otherwise the path basename:

const displayName = (project) => project.name || getFilename(project.worktree)

and the project avatar uses the same fallback:

const name = createMemo(() => props.project.name || getFilename(props.project.worktree))

The sidebar project enrichment path currently creates a child store but does not merge the child workspace's persisted projectMeta into the project before rendering:

function enrich(project) {
  const [childStore] = serverSync.child(project.worktree, {
    bootstrap: false
  })
  const projectID = childStore.project
  const metadata = projectID
    ? serverSync.data.project.find((x) => x.id === projectID)
    : serverSync.data.project.find((x) => x.worktree === project.worktree)

  const base = {
    ...metadata,
    ...project
  }

  if (childStore.icon) {
    return {
      ...base,
      icon: {
        ...base.icon,
        override: childStore.icon
      }
    }
  }

  return base
}

Hovering the project tile eventually calls serverSync.child(directory) with bootstrapping enabled through the sidebar hover/aim path. That hydrates the child workspace store, after which project.name/icon data becomes available and the avatar recomputes from 1 to Y.

A narrow fix would be to merge childStore.projectMeta into enrich(project) so the last persisted custom name/icon participates in the first render:

const cached = childStore.projectMeta
const base = {
  ...metadata,
  ...cached,
  ...project,
  icon: {
    ...metadata?.icon,
    ...cached?.icon,
    ...project.icon
  }
}

A more robust fix would be to persist last-known display metadata with the globally restored server.projects entries as well, so the sidebar is never forced to render path-only project shells during Desktop/webview startup. That would avoid the first-frame mismatch even when async workspace/global metadata is not ready yet.

Environment

• OpenCode Desktop version: 1.15.13
• Platform: macOS
• Bundle identifier: ai.opencode.desktop
• Trigger: OpenCode > Reload Webview, and sometimes hide/show via Cmd+H
• Observed project list store: opencode.global.dat / server.projects.local
• Observed custom project metadata store: per-workspace workspace:project
• Symptom: project avatar fallback briefly renders from path basename before switching to custom project name/icon