@@ -194,7 +194,7 @@ from the squash message first, or use a plain merge.
 
 | Desktop identity: `packages/desktop/src/main/{index,store}.ts`, `packages/desktop/electron-builder.config{,.test}.ts`, `packages/desktop/scripts/copy-metainfo.ts`, `packages/desktop/resources/linux/opencode-desktop.desktop` (deleted), `packages/app/src/pages/layout/{deep-links.ts,helpers.test.ts}`, `packages/codev-brand/test/brand.test.ts` | appId `ai.opencode.desktop{,.beta,.dev}` → `ai.codev.desktop{,.beta,.dev}` (both copies: `APP_IDS` in main and in the builder config, plus the unpackaged fallback); deep-link scheme `opencode://` → `codev://` in all three places that must agree — `protocols.schemes`, `app.setAsDefaultProtocolClient`, and the renderer's `parseUrl` — plus the `argv.startsWith` filter the second-instance handler uses; `rpm.packageName` `opencode`/`opencode-beta`/`opencode-dev` → `codev`/`codev-beta`/`codev-dev`; the hidden `opencode-desktop.desktop` legacy launcher and its `deb`/`rpm` fpm wiring deleted. `src/main/migrate.ts` keeps the old ids — they name the *Tauri* app's directories, not ours. | The appId is the whole desktop identity: `app.setPath("userData", join(appData, appId))`, so it also names the data directory, and it drives the macOS bundle id, the Windows AppUserModelId and NSIS keys, the Linux `.desktop` filename, `executableName` and `StartupWMClass`, and the AppStream metainfo id. Leaving it as opencode meant the fork's app identified itself as upstream to the OS. Renamed as a clean cut with no data migration and no back-compat shim, on the explicit basis that there is no installed base: existing profiles under `appData/ai.opencode.desktop*` are simply orphaned (settings, session history, sandboxes and the downloaded guest image), and a packaged update across the rename would install beside the old app rather than replace it. The legacy launcher went with it — it existed to rescue GNOME/KDE pins from a superseded packaging id, and its `Exec=/opt/OpenCode/...` no longer matched any install layout. | Keep our ids and scheme; take upstream's other config. Never rename the `TAURI_APP_IDS` in `migrate.ts` to match — a blind find-and-replace there points the Tauri migration at a directory that never existed. All three deep-link sites have to move together or links open nothing; `electron-builder.config.test.ts` covers the ids, the package names and the scheme per channel. |
 
-| Code/Work workspace split: `packages/app/src/context/layout.tsx`, `packages/app/src/components/{app-sidebar,titlebar}.tsx`, `packages/app/src/i18n/{en,es}.ts` | The sidebar gains two tabs above Projects — **Code** (every non-sandbox server: the local sidecar, WSL, remote, SSH) and **Work** (the sandboxes) — backed by the fork-only `packages/app/src/workspace/{side.ts,tabs.tsx}`. `layout.tsx` stores `home.workspace` and `home.lastSession` (per side) and records the latter from an effect on `route()`; `app-sidebar.tsx` renders `<WorkspaceTabs/>`, swaps `global.servers.list()` for a side-filtered memo in all six places it indexed it, and adds an empty-state branch because a side can now have no servers at all; `titlebar.tsx` loses the Home button and its `home.toggle` command (`mod+b`) and filters the tab strip, its reorder and `tab.prev`/`tab.next` to the visible side; `effectiveSide` falls back to Code when the platform has no sandbox support or the last sandbox has been deleted, treating an unloaded sandbox list as unknown rather than empty; i18n gains `workspace.{code,work,empty.none,empty.starting}`. | Sandboxes were just another row in a list of servers, so the isolated environment and the local machine were one undifferentiated pile. Splitting them makes "am I running on my machine or in a sandbox?" a property of where you are rather than something to infer from a server name. The Home button went because it opened a draft rather than a home screen, which is the behaviour the tabs replace: a tab returns you to that side's last session, falling back to a draft and then to the home screen. All the logic lives in the fork-only module; the upstream files hold wiring only, and every section below the tabs is the same component reading a filtered list. | Keep the wiring and take upstream's surrounding changes. The six `sideServers()` call sites in `app-sidebar.tsx` were `global.servers.list()` — if upstream adds a seventh, filter it too or that branch will show sandboxes under Code. Read `useWorkspaceSide()` rather than `layout.home.workspace()`: it collapses to Code where the platform has no sandbox support, which is what keeps the web build coherent. The tab strip filter and `reorderWithinSide` go together — `tabs.reorder()` rejects a partial key list, so a filtered strip without the merge silently ignores drags. |
+| Code/Work workspace split: `packages/app/src/context/layout.tsx`, `packages/app/src/components/{app-sidebar,titlebar}.tsx`, `packages/app/src/i18n/{en,es}.ts` | The sidebar gains two tabs above Projects — **Code** (every non-sandbox server: the local sidecar, WSL, remote, SSH) and **Work** (the sandboxes) — backed by the fork-only `packages/app/src/workspace/{side.ts,tabs.tsx}`. `layout.tsx` stores `home.workspace` and `home.lastSession` (per side) and records the latter from an effect on `route()`; `app-sidebar.tsx` renders `<WorkspaceTabs/>`, swaps `global.servers.list()` for a side-filtered memo in all six places it indexed it, and adds an empty-state branch because a side can now have no servers at all; `titlebar.tsx` loses the Home button and its `home.toggle` command (`mod+b`) and filters the tab strip, its reorder and `tab.prev`/`tab.next` to the visible side; `effectiveSide` falls back to Code only where the platform has no sandbox support — deliberately not on an empty sandbox list, which is indistinguishable from one that has not loaded; `layout.tsx` also holds an effect keeping `home.selection.server` on the showing side, because a sandbox joins the server list only once it has finished starting, so the one-shot correction inside a switch cannot cover a sandbox created moments earlier; the fork-only `DialogAddSandbox` gains an `onCreated` callback so the Work gate switches on the create's own result rather than on the asynchronous sandbox list; i18n gains `workspace.{code,work,empty.none,empty.starting}`. | Sandboxes were just another row in a list of servers, so the isolated environment and the local machine were one undifferentiated pile. Splitting them makes "am I running on my machine or in a sandbox?" a property of where you are rather than something to infer from a server name. The Home button went because it opened a draft rather than a home screen, which is the behaviour the tabs replace: a tab returns you to that side's last session, falling back to a draft and then to the home screen. All the logic lives in the fork-only module; the upstream files hold wiring only, and every section below the tabs is the same component reading a filtered list. | Keep the wiring and take upstream's surrounding changes. The six `sideServers()` call sites in `app-sidebar.tsx` were `global.servers.list()` — if upstream adds a seventh, filter it too or that branch will show sandboxes under Code. Read `useWorkspaceSide()` rather than `layout.home.workspace()`: it collapses to Code where the platform has no sandbox support, which is what keeps the web build coherent. The tab strip filter and `reorderWithinSide` go together — `tabs.reorder()` rejects a partial key list, so a filtered strip without the merge silently ignores drags. |
 
 | `packages/app/src/context/global.tsx` | Two lines: imports `seedSandboxProjects` from the fork-only `packages/app/src/sandbox/projects.ts` and calls it with `server.list` + `ensureServerCtx`, beside the memo that already creates a ctx per connection. All the logic lives in the fork-only module. | A sandbox exposes exactly one directory (`/workspace` on vz/bwrap, the wslpath translation on WSL) and the guest registers it as its own project, but the app's per-server project list starts empty and nothing ever fills it. With no project, every "New session" entry point — `home-model.openNewSession`, the titlebar's `openNewTab` fallback chain — finds nothing for that server and falls back to another one, so the sandbox looks selected while the session runs on the local server. The seed reads `sync.data.path.directory`, which every server ctx already fetches, so it stays backend-agnostic. The same module also names that project after the sandbox's host folder (via `client.project.update`, the call behind rename-project), because the guest sees only its mount point and every sandbox would otherwise read "workspace" in the sidebar, tabs and palette. | Keep both lines; take upstream's other changes to the file. The call must stay inside the Global context init (it needs `ensureServerCtx`) — `SandboxesProvider` is mounted above `GlobalProvider` in `app.tsx`, so it cannot live there. |
 
 
@@ -18,7 +18,7 @@ import type { ProjectAvatarVariant } from "@opencode-ai/ui/v2/project-avatar-v2"
 import { migrateLegacySessionStateKeys, ServerScope, SessionStateKey } from "@/utils/server-scope"
 import { createSessionKeyReader, ensureSessionKey, pruneSessionKeys } from "./layout-helpers"
 import { requireServerKey } from "@/utils/session-route"
-import { sideForServerKey, type WorkspaceSide } from "@/workspace/side"
+import { selectionForSide, serversForSide, sideForServerKey, type WorkspaceSide } from "@/workspace/side"
 import { type DraftTab, useTabs } from "./tabs"
 import { closeSessionTab, openSessionTab, previewSessionTab, type SessionTabs } from "./layout-tabs"
 
@@ -316,6 +316,22 @@ export const { use: useLayout, provider: LayoutProvider } = createSimpleContext(
       sessionTabPreview: {} as Record<string, string | undefined>,
     })
 
+    // Fork: keep the sidebar's selection on the side that is showing. Switching
+    // sides corrects it once, but a sandbox joins the server list only when it
+    // finishes starting — so right after one is created there is nothing on the
+    // Work side to select yet, and without this the projects list would show
+    // the sandbox while Pinned and Recents still read the local server.
+    createEffect(() => {
+      const side = store.home.workspace ?? "code"
+      const available = serversForSide(server.list, side)
+      if (!available.length) return
+      const target = selectionForSide(server.list, side, store.home.selection.server)
+      if (!target) return
+      const key = ServerConnection.key(target)
+      if (store.home.selection.server === key) return
+      setStore("home", "selection", reconcile({ server: key }))
+    })
+
     // Fork: remember where each side was, so switching back to Code or Work
     // returns you to the session you were reading rather than a blank draft.
     // Recorded here rather than in the sidebar because it has to keep working
 
@@ -9,14 +9,19 @@ import { Show } from "solid-js"
 import { createStore } from "solid-js/store"
 import { useLanguage } from "@/context/language"
 import { usePlatform } from "@/context/platform"
+import type { SandboxConfig } from "./types"
 import { useSandboxes } from "./context"
 import { sandboxResourcesValid } from "./resources"
 
 // Distribution and directory names are derived from the sandbox name across
 // every backend, so keep it to characters that are safe in all of them.
 const NAME_PATTERN = /^[A-Za-z0-9][A-Za-z0-9._-]*$/
 
-export function DialogAddSandbox() {
+// onCreated fires with the new sandbox before the dialog closes. Callers that
+// need to react to a creation must use it rather than watching the sandbox
+// list: that list arrives over a separate IPC event, so it is still empty for
+// a beat after add() resolves.
+export function DialogAddSandbox(props: { onCreated?: (config: SandboxConfig) => void }) {
   const language = useLanguage()
   const platform = usePlatform()
   const dialog = useDialog()
@@ -79,7 +84,10 @@ export function DialogAddSandbox() {
         store.projectDir,
         resourcesApply() ? { cpus: cpus(), memoryMiB: memoryMiB() } : undefined,
       )
-      if (created) dialog.close()
+      if (created) {
+        props.onCreated?.(created)
+        dialog.close()
+      }
     } catch (error) {
       showToast({
         variant: "error",
 
@@ -10,20 +10,17 @@ export type WorkspaceSide = "code" | "work"
 
 export const WORKSPACE_SIDES = ["code", "work"] as const
 
-// Sandboxes are a desktop feature, so the web build has no Work side at all,
-// and deleting the last sandbox leaves Work with nothing to show. Either way
-// the sidebar must not sit on a side it cannot populate.
+// Sandboxes are a desktop feature, so the web build has no Work side at all.
+// A persisted "work" from a desktop session must not strand the sidebar on a
+// side that platform can never populate.
 //
-// `sandboxCount` is undefined until the sandbox list has loaded: treating that
-// as zero would bounce every launch back to Code before the answer arrives.
-export function effectiveSide(
-  side: WorkspaceSide,
-  sandboxesSupported: boolean,
-  sandboxCount?: number,
-): WorkspaceSide {
-  if (!sandboxesSupported) return "code"
-  if (side === "work" && sandboxCount === 0) return "code"
-  return side
+// Deliberately not also collapsing when there are zero sandboxes: the sandbox
+// list arrives asynchronously, so "none" and "not loaded yet" look identical
+// here, and treating them alike bounced the user back to Code both on every
+// launch and in the beat after creating their first sandbox. An empty Work
+// side is a legible state — WorkspaceEmpty says so and offers to create one.
+export function effectiveSide(side: WorkspaceSide, sandboxesSupported: boolean): WorkspaceSide {
+  return sandboxesSupported ? side : "code"
 }
 
 // The sandbox key format (sandbox:<name>) is persisted in the main-process
 
@@ -17,10 +17,7 @@ import { effectiveSide, selectionForSide, WORKSPACE_SIDES, type WorkspaceSide }
 export function useWorkspaceSide() {
   const layout = useLayout()
   const platform = usePlatform()
-  const sandboxes = useSandboxes()
-  return createMemo(() =>
-    effectiveSide(layout.home.workspace(), !!platform.sandboxes, sandboxes.state.data?.sandboxes.length),
-  )
+  return createMemo(() => effectiveSide(layout.home.workspace(), !!platform.sandboxes))
 }
 
 // Code and Work are the same UI pointed at different servers, so switching one
@@ -81,12 +78,11 @@ export function useWorkspaceSwitch() {
       // side where it was, which is how the user stays on Code.
       if (next === "work" && !hasSandbox()) {
         void import("@/sandbox/dialog-add").then((module) => {
-          void dialog.show(
-            () => <module.DialogAddSandbox />,
-            () => {
-              if (hasSandbox()) enter("work")
-            },
-          )
+          // Switch off the dialog's own result, not off the sandbox list: the
+          // list arrives on a separate IPC event and is still empty for a beat
+          // after the create resolves, so checking it here left the user on
+          // Code until they toggled the tabs by hand.
+          void dialog.show(() => <module.DialogAddSandbox onCreated={() => enter("work")} />)
         })
         return
       }
 
@@ -106,15 +106,9 @@ test("collapses to Code where sandboxes are unsupported", () => {
   expect(effectiveSide("code", false)).toBe("code")
 })
 
-// Deleting the last sandbox from Settings while Work is open would otherwise
-// leave the sidebar on a side with nothing in it.
-test("falls back to Code once the last sandbox is gone", () => {
-  expect(effectiveSide("work", true, 1)).toBe("work")
-  expect(effectiveSide("work", true, 0)).toBe("code")
-})
-
-// undefined is "not loaded yet", not "none": treating it as zero would bounce
-// every launch back to Code before the sandbox list arrives.
-test("keeps the persisted side while the sandbox list is still loading", () => {
-  expect(effectiveSide("work", true, undefined)).toBe("work")
+// An empty Work side stays selected: the sandbox list loads asynchronously, so
+// collapsing on "no sandboxes" also fires before the list arrives and in the
+// beat after the first one is created.
+test("keeps Work selected even with no sandboxes", () => {
+  expect(effectiveSide("work", true)).toBe("work")
 })