feat(opencode): add --resume session picker

[quinnjr]

Issue for this PR

Closes#36134

Refs #18569 — the picker covers the "find and resume an old session" friction there, but resuming by session name (what it literally asks for) is not part of this PR.

Type of change

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

What does this PR do?

Adds opencode --resume (and opencode attach --resume): boots the TUI straight into the existing session picker for the current directory. This is option A from the linked issue.

Today, resuming anything but the latest session means either opencode session list + copy-pasting an opaque ses_... id into -s, or booting the TUI and opening /sessions by hand. Claude Code (claude --resume opens its picker) and Codex (codex resume opens a picker scoped to the cwd, --last for most recent) both ship this; not having it is recurring friction for people switching over (both linked issues).

Implementation:

• --resume flag on the default command and attach; mutually exclusive with --continue/--session, rejected with --mini (no picker surface there). Headless run intentionally untouched, per the issue's scope.
• Bootstrap now awaits the session list in the blocking phase for --resume (previously --continue-only), then opens DialogSessionList — the same dialog /sessions uses, directory-scoped; no new UI.
• Empty result shows a toast instead of an empty dialog; the check uses the picker's own query so the two can't disagree (the startup store list has a 30-day cutoff the dialog doesn't).
• With zero providers configured, the picker waits for provider setup instead of being replaced by the provider dialog at startup.
• --fork still requires --continue/--session; forking from the picker would need fork-on-select in the dialog and is deliberately out of scope.
• CLI reference row added (English; translations sync separately).

How did you verify your code works?

• New tests: CLI flag-validation cases (test/cli/tui/thread.test.ts), bootstrap blocking/fetch-once for resume (packages/tui/test/cli/cmd/tui/sync-resume.test.tsx), and app-lifecycle tests for picker-opens vs toast-when-empty (packages/tui/test/app-lifecycle.test.tsx). Regenerated the attach --help snapshot.
• bun test from packages/opencode (15 pass) and packages/tui (28 pass); bun typecheck clean in both; repo-wide typecheck also ran green via the pre-commit hook.
• Manual: bun dev --resume in a directory with sessions -> picker opens (below), selecting one resumes it; in a directory with none -> toast. --resume --continue, --resume --mini, --resume --fork all exit 1 with clear errors.
• Repro: bun dev --resume in any directory with sessions.

Screenshots / recordings

opencode --resume in a directory with existing sessions:

 Sessions esc
Search
Today
Opencode session management framework feature branch
Next expected Intel CPU release date
Wed Jul 22 2026
Bunenv installation and zshenv path configuration
pin/unpin ctrl+f delete ctrl+d rename ctrl+r

Checklist

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

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Potential duplicate found:

• PR feat(opencode): open session list with --resume #35023: feat(opencode): open session list with --resume
  • This appears to be an earlier/related attempt at the same feature. It addresses the same issue ([FEATURE]: Add session picker entry point at startup (e.g. -r, --resume or -s without value) #36134) to add --resume functionality that opens a session picker. The current PR (38878) likely supersedes or iterates on this work.

No other duplicate PRs were found. PR #26432 and #36774 are related to session picker functionality but address different concerns (root sessions request and crash prevention respectively).

[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.