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.