[Feature]: Import sessions from a shared OpenCode server

[bbauti]

I use T3 Code with an already-running OpenCode server. This creates a workflow
that T3 Code does not currently represent: an OpenCode session may be started
from another OpenCode client, while T3 Code is connected to the same server and
workspace.

Those sessions remain usable in OpenCode, but they do not appear as T3 threads.
Before opening a pull request, I would like to understand whether this is a
workflow T3 Code wants to support and what the intended product boundary should
be.

I explored two substantially different approaches in a fork:

Fork: https://github.com/bbauti/t3code

Option A: explicit import

Branch:
https://github.com/bbauti/t3code/tree/feat/import-opencode-session

Size: 847 changed lines versus origin/main, including tests and docs.

This adds an Import OpenCode session action under Settings → Projects.

It:

• Queries configured external OpenCode servers only when requested.
• Lists root sessions belonging to the selected project workspace.
• Excludes archived, child, T3-owned, already-bound, and currently busy sessions.
• Copies the selected text history into a new T3 thread.
• Persists the exact OpenCode server and session identity.
• Resumes future prompts only against that same upstream session.
• Uses approval-required permissions for the imported session.

This is deliberately a one-time import rather than background synchronization.

UI

Desktop

Mobile

Option B: automatic and live adoption

Branch:
https://github.com/bbauti/t3code/tree/feat/adopt-external-opencode-sessions

Size: 12,147 changed lines versus origin/main.

This was the broader experiment. It automatically discovers sessions created
outside T3 Code and adopts them as live T3 threads.

Supporting active sessions required considerably more machinery:

• Durable ownership across OpenCode servers and T3 environments.
• Canonical workspace matching.
• Paginated history hydration.
• Subscribing before hydration and reconciling concurrent events.
• Message and part deduplication.
• Busy, idle, retry, cancellation, and turn-completion recovery.
• Pending approval and question recovery.
• Restart and reconnect handling.
• Archival and deletion reconciliation.

The experiment helped identify the real edge cases, but its scope is clearly
too large for an unsolicited contribution.

The active-session question

The reduced branch currently excludes busy sessions because it performs a
one-time history snapshot. Simply removing that check would introduce a race:
OpenCode could append or revert messages while T3 is reading the paginated
history, and events emitted before T3 subscribes could be lost.

There seem to be three possible product choices:

1. Import only sessions that are already idle.
2. Show busy sessions and offer Import when finished.
3. Adopt busy sessions live, accepting the additional synchronization and
   lifecycle complexity.

My current preference is option 2 if importing active work matters: it preserves
the narrow explicit model without pretending a changing transcript is a stable
snapshot.

Related discussions

This overlaps with:

• Bi-directionally sync t3.code threads with provider threads #876, which proposed automatic bidirectional provider synchronization.
• request: import or recreate sessions from Codex #6680, which discusses importing or recreating existing Codex sessions.

The explicit-import option here is intentionally narrower than #876: it is
manual, project-scoped, and does not populate T3 with every provider session or
folder automatically.

Feedback requested

• Is this workflow worth supporting?
• Should busy sessions remain unavailable, be queued until idle, or be adopted live?
• Is there a smaller product or architectural boundary you would prefer?

---

I have not opened either pull request. The goal of this discussion is to avoid
sending a large or directionally unwanted contribution and to get feedback from
maintainers and other OpenCode users first.

---

Implementation disclosure: the reduced branch was made with GPT-5.6 Sol in
T3 Code. The broader exploratory branch also used GPT-6 Astra, Fable 5.1, and
Opus 5.