desktop: new-session project chip never reflects sibling directories of the same git repo #55351

Activity

1. opencode-agent commented on Oct 14, 2026

   

   opencode-agentBot

   on Oct 14, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed report and root-cause analysis. I could reproduce this.

   How I tested it

   • The OpenCode web UI, which is the same front end the desktop app uses (I didn't run the desktop app itself).
   • Three plain clones of one repo (app-dev, app-uat, app-release), with opencode serve started from app-dev.
   • The project record set up so GET /api/project returns one project with app-dev as canonical and the other two clones in sandboxes, as in your report.
   • All three directories added as projects.

   What happened

   • Starting a new session from app-uat shows app-dev on the chip.
   • Picking app-uat, then app-release, from the dropdown updates the selected directory each time, but the chip label and the checkmark stay on app-dev.

   This happens on v2.0.28 and still happens on the latest dev (34d8ded). The resolver in packages/app/src/new-session/project/selector.tsx is the single find() over both conditions that you described.

   One side note: v2's server never fills in sandboxes on its own. Only the v1-to-v2 migration writes it, so your project data probably came from v1.

   The recording below shows it on dev, the screenshots show the dropdown after picking app-release on both versions, and the script below reproduces it.

   recording.mp4

   

   

   Reproduction script (repro.mjs)

   // Reproduces anomalyco/opencode#55351 in the OpenCode v2 web UI (same renderer as Desktop).
   // Prereqs: three plain clones of one repo at /tmp/opencode/clones/{app-dev,app-uat,app-release},
   // an `opencode serve` started from app-dev, and that project's `sandboxes` holding the other two
   // clones (as in the report's GET /api/project output; seeded in the DB here).
   // Usage: bun repro.mjs <ui-url> <server-url> <server-password> <sqlite-db-path>
   import { chromium } from "playwright"
   import { Database } from "bun:sqlite"
   
   const [ui, server, password, db] = process.argv.slice(2)
   const root = "/tmp/opencode/clones"
   const dirs = ["app-dev", "app-uat", "app-release"].map((d) => `${root}/${d}`)
   
   // Data the report takes as given: one project record, sibling clones listed in sandboxes.
   new Database(db).run("update project set sandboxes = ? where worktree = ?", [JSON.stringify(dirs.slice(1)), dirs[0]])
   console.log(await (await fetch(`${server}/api/project`, { headers: { authorization: "Basic " + btoa(`opencode:${password}`) } })).text())
   
   const b = await chromium.launch()
   const ctx = await b.newContext({ viewport: { width: 1400, height: 900 }, recordVideo: { dir: "/workspace/repro/video" } })
   const p = await ctx.newPage()
   await p.goto(ui)
   await p.waitForTimeout(3000)
   await p.getByText("Use password").click()
   await p.fill("#server-connect-url", server)
   await p.fill("#server-connect-password", password)
   await p.getByRole("button", { name: "Connect" }).click()
   await p.waitForTimeout(4000)
   // Add all three clones as projects (as Desktop does).
   await p.evaluate((dirs) => {
     const k = "opencode.global.dat:server"
     const v = JSON.parse(localStorage.getItem(k))
     const entries = dirs.map((worktree) => ({ worktree, expanded: true }))
     // the scope key is "local" for the same-origin server and the URL otherwise
     for (const key of ["local", ...v.list.map((s) => s.http.url)]) v.projects[key] = entries
     localStorage.setItem(k, JSON.stringify(v))
   }, dirs)
   await p.reload()
   await p.waitForTimeout(4000)
   const state = () => p.evaluate(() => JSON.stringify(JSON.parse(localStorage.getItem("opencode.global.dat:server")).lastProject))
   
   await p.getByText("app-uat", { exact: true }).first().click()
   await p.waitForTimeout(1500)
   await p.getByRole("button", { name: "New session" }).first().click()
   await p.waitForTimeout(3000)
   const chip = p.getByText(/^app-/).last()
   console.log("new session from app-uat -> chip:", (await chip.innerText()).trim(), "| lastProject:", await state())
   await p.screenshot({ path: "/workspace/repro/01-new-session.png" })
   
   for (const target of ["app-uat", "app-release"]) {
     await chip.click()
     await p.waitForTimeout(1000)
     await p.getByText(target, { exact: true }).last().click()
     await p.waitForTimeout(2000)
     console.log(`picked ${target} -> chip:`, (await chip.innerText()).trim(), "| lastProject:", await state())
   }
   await chip.click()
   await p.waitForTimeout(1000)
   await p.screenshot({ path: "/workspace/repro/dropdown-after-pick.png" })
   await p.keyboard.press("Escape")
   await p.waitForTimeout(500)
   await ctx.close()
   await b.close()

   Run it: bun repro.mjs
2. opencode-agent

   added

   reproduced

   on Oct 14, 2026
3. brettjohnsen-sy commented on Nov 3, 2026

   

   brettjohnsen-sy

   on Nov 3, 2026

   More actions

   Also seeing related behavior on OpenCode Desktop 2.2.5 on macOS (Apple Silicon), with two independent clones of the same Git remote. Their .git directories are separate; they are not linked worktrees.

   1. Add /path/repo-main in the desktop app.
   2. Add /path/repo-pr using the Projects folder-plus button.
   3. The second clone does not appear as a separate Projects entry; the new-session project name and displayed path refer to repo-main.
   4. Start a session and run pwd: it correctly reports /path/repo-pr. The session breadcrumb also shows the PR directory, so this is not evidence that edits run in the wrong clone.

   The impact extends beyond the selector label: without a separate project entry, the user cannot easily browse the PR clone’s prior session history in the desktop UI. The session API does return prior sessions for /path/repo-pr, so the history exists.

   Expected: independently selected clone directories should be clearly distinguishable in the UI, with a way to browse each directory’s history, even if they share a project identity internally. The issue description says the sidebar rows are unaffected; this report may be a related but distinct sidebar/history problem on 2.2.5. No screenshots or private repository details included.