Web: New Session does nothing when no project has been opened #37606

Activity

1. github-actions

   assigned

   Brendonovich

   on Jul 18, 2026
2. solace-lee commented on Jul 20, 2026

   

   solace-lee

   on Jul 20, 2026

   More actions

   +1, can reproduce on Windows + opencode 1.18.3 with additional diagnostics

   Same symptom as OP. Some extra details that might help narrow the fix:

   Environment

   • Windows 11, Chrome/Edge (latest)
   • opencode web (default port 4096, loopback only)
   • opencode version: 1.18.3 (running on C:\Users\Solac)
   • Loaded plugin: oh-my-openagent (irrelevant — issue reproduces without per OP)
   • Browser localStorage cleared / fresh profile
   • No project added to the opened-project list

   Diagnostics beyond OP's report

   1. POST /api/session works fine from fetch() in DevTools console — backend is healthy.
   2. The titlebar button (button[aria-label="新建会话"]) exists, disabled=false, correct position.
   3. Programmatic button.click() does NOT navigate and does NOT call any fetch — i.e. the click handler is not bound / is a no-op. This rules out "calls API but UI doesn't update".
   4. Console is silent (zero errors, zero warnings during the click).
   5. Workaround that works: bind a manual listener to keydown and fetch('/api/session', {method:'POST', headers:{'Content-Type':'application/json'}, body:'{}'}) then location.href = '/' + data.data.id. The frontend API + render path is fine; only the titlebar button is broken.

   Hypothesis: the titlebar New Session action returns early because no project is selected, and the fallback path to sdk.directory (which OP mentions in the issue body) isn't wired up — so the click handler runs but produces no side effect.

   Linking for triage: #37607
3. lilxckd-cloud commented on Jul 30, 2026

   

   lilxckd-cloud

   on Jul 30, 2026

   More actions

   Independent reproduction on 1.18.9 (arm64, Jetson / Ubuntu 20.04), opencode serve --hostname 0.0.0.0, accessed from another machine on the LAN.

   Confirming the key diagnostic detail: clicking the titlebar New Session button issues no network request at all. Captured with Chrome DevTools Protocol against a fresh profile with empty localStorage — zero Network.requestWillBeSent events on click, no console exception, no navigation. That rules out the server and points squarely at the client-side early return.

   Where it stops

   packages/app/src/components/titlebar.tsx, in openNewTab():

   const fallback = global.servers.list().flatMap((conn) => {
     const project = global.ensureServerCtx(conn).projects.list()[0]
     return project ? [{ server: ServerConnection.key(conn), project }] : []
   })[0]
   if (!fallback) return   // <- fresh profile lands here and nothing happens

   layout.projects.list() and every server's projects.list() are empty on a fresh profile, so the handler returns before creating a draft.

   As this issue notes, the server directory is already available and correct at that moment:

   $ curl -s http://localhost:7788/path
   {"home":"/home/ipzero","state":"...","config":"...","worktree":"/mnt/data/chat","directory":"/mnt/data/chat"}
   
   $ curl -s http://localhost:7788/api/location
   {"directory":"/mnt/data/chat","project":{"id":"766521aa...","directory":"/mnt/data/chat"}}

   Why it isn't just cosmetic

   On this setup the button is the only way in, because Add Project is also broken (#37611 — the empty filter returns nothing, so the picker shows "No folders found"). With both failing, a fresh browser cannot open a project or create a session at all. The portal is unusable until you either type an absolute path into the picker or hand-edit localStorage.

   Worth noting for anyone triaging: the two bugs mask each other, which is probably why this keeps getting refiled (#39100, #38411, #37227).

   On PR #37607

   The approach there — falling back to the /path directory — matches what the evidence supports. It no longer applies cleanly to dev, though: newSessionProject in packages/app/src/pages/home.tsx no longer exists in its patched form, so the home.tsx hunk is stale.

   I have an equivalent fix rebased on current dev (titlebar fallback + projects.open/touch so the directory is remembered). Verified on the reproduction above: the same click now fires 31 requests, navigates to /new-session?draftId=..., renders the composer, and persists the directory as the opened and last project. bun run test:unit in packages/app goes from 692 to 694 passing with no new failures (the one pre-existing i18n parity failure is present on clean dev too), and bun run typecheck is clean. Happy to open it if that's useful, or to leave the field to #37607 if a maintainer would rather revive that one.
4. github-actions commented on Sep 29, 2026

   

   github-actionsBot

   on Sep 29, 2026 – with GitHub Actions

   Contributor

   More actions

   To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
5. github-actions

   closed this as not plannedon Sep 29, 2026