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

[telles0808]

Description

In the desktop app, clicking New session while a project is selected creates the session bound to the shared service's default location (the user home) instead of the selected project directory. The session runs and is open in a tab, but that project's session list stays empty ("Nada por aqui ainda", badge 0), so the chat looks lost.

Plugins

None.

OpenCode version

2.0.16 (desktop app, channel latest)

Steps to reproduce

1. Make the shared service's default location be the user home (here it was C:\Users\<user> after the app restarted with cleared persisted state).
2. In the desktop app select project D:\<path>\00 - Pesca and click New session.
3. Send one message so the session is persisted.
4. Inspect the API: GET /api/session/<id> returns location.directory = C:\Users\<user> (not the selected project), and GET /api/session?directory=D:\<path>\00 - Pesca returns []. The project UI shows 0 sessions while the session tab is open.

Screenshot and/or share link

N/A - described above.

Operating System

Windows 11 - Windows NT 10.0.26200 (win32 x64)

Terminal

OpenCode Desktop (Electron 44 / Chrome 152), not a terminal.

Additional context

• Server log: worktree discovery failed directory="C:\Users\<user>" strategy=git.
• Workaround: POST /api/session/<id>/move {"directory":"D:\<path>\00 - Pesca"} (the session_move tool) rebinds the session; it then appears in the project list.
• Expected: the client should pass the selected project directory when creating a session and the server must not silently fall back to its default location; a session open in a tab should always be listed under its project.

[Engine523]

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.