session: new session created from a project binds to the service default location and is missing from that project's history #51196

Activity

1. Engine523 commented on Sep 29, 2026

   

   Engine523

   on Sep 29, 2026

   More actions

   Additional repro with git worktrees (sandboxes): a new session falls back to the project's canonical (main worktree) directory

   Same root symptom as this issue, but with a different fallback target, which suggests the desktop client sends the project's canonical directory rather than no path at all.

   Environment

   • OpenCode 2.0.18 (desktop app, channel latest), opencode-cli v2.0.18
   • Windows 11 25H2 (build 26200, win32 x64)
   • OpenCode Desktop (Electron), not a terminal

   Steps to reproduce (reproduced on two independent repositories)

   1. Repo A: main worktree C:\repos\app-a + git worktree C:\repos\app-a-wt1. Both resolve to the same projectID; GET /api/project shows canonical: C:\repos\app-a, sandboxes: [C:\repos\app-a-wt1].
   2. In the desktop app: New session -> select the worktree project (app-a-wt1) -> send one message.
   3. Result: the session is created with location.directory = C:\repos\app-a (the canonical main worktree), not the selected worktree. GET /api/session?directory=...app-a-wt1 shows no new session; it shows up under the main directory instead.
   4. Repeated with Repo B (C:\repos\app-b + worktree C:\repos\app-b-wt1, separate projectID): identical result - two new sessions created while the worktree was selected both landed in C:\repos\app-b (canonical), zero new sessions in the worktree. This still happened while a session inside the worktree was open with its context (MCP servers, file watchers) fully initialized for the worktree directory, so it is not a stale-UI-state issue.

   The server is not at fault (verified against the local API)

   • POST /api/session with body {"location":{"directory":"<worktree path>"}} creates the session correctly: projectID = the repo's project, location.directory = the worktree path. (Side note: the directory must be passed via location in the body; a top-level directory field is silently ignored and the session then falls back to the service default location - possibly related to Windows: global-project session path depends on server process drive, hides API-created sessions from desktop picker #51258.)
   • So the v2 server honors an explicitly provided sandbox location; the desktop client simply never sends the selected worktree.

   Regression

   The same flow on desktop 1.18.x (verified on 9/11, 9/21 and 9/28 with v1.18.30/31/32) created sessions correctly inside the worktree directory.

   Workarounds

   • POST /api/session/<id>/move {"directory":"<worktree>"} (the session_move tool) rebinds an already-created session - same as the original report.
   • POST /api/session/<existing-sandbox-session-id>/fork - the fork route body has no location field, so a fork inherits the parent session's location; forking any existing worktree session yields a new session in the worktree.
   • Or run opencode from the worktree directory in a terminal.

   Expected

   The client should pass the location the user actually selected (including a sandbox/worktree) when creating a session; at minimum, selecting a worktree must not silently bind the new session to the canonical main worktree.

   Server logs and API dumps available on request.
2. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   Contributor

   More actions

   Thanks for the detailed report and the API output, it helped a lot.

   I tried to reproduce this on 2.0.16 but couldn't fully: this needs the Windows desktop app, and I only have Linux here. Against the 2.0.16 server, creating a session with an explicit location.directory (a git project folder with spaces in its name, like yours) saved it under that folder, and GET /api/session?directory=... listed it. So the server keeps a location when the client sends one, and the problem is most likely in which location the desktop app sends for New session on Windows. This may be linked to the worktree discovery failed error for your home folder after the saved state was cleared.

   A maintainer with Windows and the desktop app will need to look at this. If you can, it would help to know whether it still happens:

   • after restarting the app normally, without clearing its saved state
   • with a project on the C: drive

   Until then, your workaround of moving the session with POST /api/session/<id>/move is the best option.