[Windows] Non-git projects get an absolute session.path, hiding those sessions from the TUI session list

[xiaobright]

Description

session.path is supposed to be the session directory relative to the project worktree, but for non-git projects on Windows it is written as an absolute path. The TUI session picker filters on the relative value, so those sessions are never listed — even though they are intact in opencode.db and opencode export <id> still works.

Root cause is in packages/core/src/session.ts (dev @ 95daf906):

const project = yield* projects.resolve(input.location.directory)
...
path: path.relative(project.directory, input.location.directory).replaceAll("\\", "/"),

For a non-git directory the resolved project directory is "/" (the global project row in project has worktree = '/'). On Windows / is resolved against the current process drive, so path.relative("/", "E:/Desktop/x") is a cross-drive relative and Node returns the absolute path unchanged. The row therefore gets path === directory.

The same happens to a C: directory if the process was started from another drive. In my DB the bad rows just happen to be the E: ones — it is the process drive that decides, not the directory.

The picker's filter (packages/opencode/src/session/session.ts, listByProject) is:

eq(SessionTable.path, input.path)
like(SessionTable.path, `${input.path}/%`)
and(isNull(SessionTable.path), eq(SessionTable.directory, input.directory))

An absolute path matches none of the three.

Plugins

None.

OpenCode version

session.version on the 26 affected rows: local 17, 1.18.19 5, 1.18.25 3, 1.18.15 1. The root cause is still present in dev at 95daf906.

Steps to reproduce

1. On Windows, open a non-git directory on a drive other than the one the process runs from (e.g. E:\work while the app lives on C:).
2. Create a session there.
3. Open the TUI in the same directory and look at the session list. The session is missing; it appears if the query is re-run with the absolute value.

Screenshot and/or share link

No screenshot — there is no visual difference beyond the missing list entries. The DB evidence is below.

Operating System

Windows 11 (10.0.26200)

Terminal

No response

Evidence from my DB (271 sessions, shared by the v1 CLI and the v2 desktop / dev builds)

• 245 rows: path relative
• 26 rows: path absolute, and all 26 are byte-identical to directory
• all 26 are on E:, none on C:

So it only shows up on a non-system drive, which makes it look intermittent. Replaying the picker's query against my DB: the relative form matches 53 sessions for that directory, the absolute form matches 9 — the absolute ones are exactly the missing ones.

Expected behavior

path stays relative to the worktree, or the picker tolerates both forms.

Related

• Upgrade to 1.17.x hides pre-existing sessions — new path column not back-filled during migration #35750 (auto-closed for inactivity) has the same symptom from a different cause: there path was NULL after the column was added, not absolute.
• Web UI does not list SVN sessions on Windows #48508 may be the same bug. SELECT count(*) FROM session WHERE project_id = 'global' AND path LIKE '_:/%' on the reporter's DB would confirm it.
• PR fix: keep sessions discoverable for non-git projects on Windows #40503 described exactly this mechanism ("non-git projects use worktree / … resolves to the drive root of the current process") and was closed by the automated PR cleanup rather than by review.

Workaround for other users

With OpenCode closed, normalize the column so the relative form matches:

UPDATE session SET path = substr(path, 4) WHERE path GLOB '[A-Za-z]:/*';

Also patch the "path" value inside the matching session.created.1 / session.updated.1 rows in event, otherwise a projection rebuild restores the absolute value.

[xiaobright]

Follow-up after checking the other branches — the same expression is present on beta (line 254), just refactored:

subpath: RelativePath.make(path.relative(project.directory, location.directory).replaceAll("\\", "/")),

RelativePath is Schema.String.pipe(Schema.brand("RelativePath")) — a pure brand with no validation or normalization, so an absolute Windows path passes straight through and the cross-drive case is still unfixed. A fix needs to land on both dev and beta.

(The 2.0 branch is stale — last commit 2026-04-13 — and does not contain packages/core/src/session.ts.)

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Web UI does not list SVN sessions on Windows #48508: Similar symptom — sessions from non-git (SVN) projects on Windows are not listed in the Web UI; same underlying cause of sessions being assigned to project_id = global and the path/filter logic not matching them.

[xiaobright]

On the duplicate hint: #48508 is probably the same family, but the report does not confirm it.

Their directory is C:\projects\my_svn_project. On Windows path.relative("/", "C:/projects/x") is correct as long as the process runs from C:; it only returns an absolute path when the current process drive is a different one. So the symptom there needs either a non-C: directory or a process started from another drive.

If the #48508 reporter can run:

SELECT id, path, directory FROM session WHERE project_id = 'global' AND path LIKE '_:/%';

and gets rows back, then it is this bug and the migration in #48772 repairs them. If it comes back empty, the cause is elsewhere — likely the workspace_id IS NULL part of their report, which this does not touch.

[opencode-agent]

Thanks for the detailed report. This has already been fixed on the v2 branch by #45107: non-git folders now get their own project, so new sessions no longer store the cross-drive absolute path described here. Sessions created by older V2 builds can still have the incorrect path saved in the database and may remain hidden until that stored data is normalized. The V1-written sessions described in this report are not the affected rows. Closing because current v2 no longer creates them.