[armancharan]

Issue for this PR

Closes #37435

#37435

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

session list was loading a full instance just to query the db, which can take a long time. Skip that, resolve the project from cwd, and list by project id.

How did you verify your code works?

• bun test test/cli/session-list-bootstrap.test.ts test/server/session-list.test.ts
• session list does not run InstanceBootstrap plugins — plugins stay unloaded for session list (still run for agent list)
• filters by projectID when projectID is provided — lists only this project's root sessions; excludes children and other projects

Acceptance

Claim	Test
Skip InstanceBootstrap for session list	session list does not run InstanceBootstrap plugins
Still project-scoped via projectID	filters by projectID when projectID is provided

Screenshots / recordings

n/a

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[armancharan]

subject to feedback from code owners, i think this ordering variant — where the ID-related properties are colocated — would be better

Suggested change

	projectID?: ProjectV2.ID
	scope?: "project"
	path?: string
	workspaceID?: WorkspaceV2.ID
	scope?: "project"
	path?: string
	projectID?: ProjectV2.ID
	workspaceID?: WorkspaceV2.ID

[CRSS72]

This PR looks like it fixes a correctness bug I hit too, not just the hang — wanted to add reproduction evidence in case it's useful for review/priority.

Setup: opencode serve (headless, not Desktop) v1.18.11, reproduced again after upgrading to v1.18.13. Windows, run as a background service, multiple projects in the same opencode.db.

Symptom: GET /session?projectID=<real-id> (and ?directory=<real-worktree-path>) doesn't filter at all — it returns sessions from every project in the database, and every returned object has projectID: "global" regardless of its actual project.

Database ground truth (opencode db query) shows the correct per-project scoping exists in storage:

-- project table
id worktree
a8cf629a... C:/DEV/XYZ

-- session table, correctly linked
id title project_id
ses_02fabdb6d... XYZ backend audit a8cf629a...

But the API response for GET /session?projectID=a8cf629a... returns 7 sessions spanning 3 unrelated projects, all labeled projectID: "global".

Downstream impact: breaks the bundled web UI's per-project session list — a project with real history shows "Nothing here yet" because the client-side match against the real project ID never finds anything (everything's global). Confirmed across desktop Chrome and iOS Safari/Chrome, so it's server-side, not a rendering bug. Desktop app doesn't show this, consistent with it not routing through this same listing path.

Given this PR's test explicitly covers "filters by projectID when projectID is provided — excludes ... other projects," it looks like this change fixes exactly this. Happy to test against the branch if that'd help move it along — this one's been blocking remote/mobile access to existing sessions for me.

[MuskanPaliwal]

This might also help with a downstream issue I opened in Entire: entireio/cli#1992.

The idea there is to use opencode session list --format json so Entire can help users find and attach OpenCode sessions that its hooks never saw. While testing this with OpenCode 1.18.16, I noticed that:

opencode --pure session list --format json

rewrites .opencode/package-lock.json.

Since this PR avoids InstanceBootstrap and plugin initialization, it looks like it may also prevent that write, though I haven’t tested the PR branch yet.

Would it make sense to add a regression test checking that session list does not create or modify .opencode/package.json, .opencode/package-lock.json, other lockfiles, or node_modules? That would help confirm that downstream tools can safely use the command in a dirty worktree.

[github-actions]

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.