You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Follow-up to #23 (resume an existing session into the mesh). The session-resume plan ships claude resume first (claude --resume <id> --fork-session) and has the opencode connector throw on resume for now. This issue tracks lighting up opencode for real.
The design already accommodates it
resume is generic by construction, so opencode is a connector-internal change only — no core or CLI/manager/MCP changes:
Core carries an opaque LaunchOpts.resume?: string — "a prior-session id to fork from" — which is exactly what opencode needs too (opencode run/attach --session <id> --fork, same fork-never-reuse contract as claude's --fork-session).
The three imperative paths (foreground cotal spawn --resume, cotal start --resume, MCP cotal_spawn(resume=…)) forward the string connector-agnostically.
So the only edit is inside @cotal-ai/connector-opencode: replace the buildLaunch throw with real rendering.
Why it was deferred (the actual work)
Unlike claude (a pure argv flag), the opencode connector runs a headless opencode serve + an in-process plugin that creates the ONE session it drives, then attaches a viewer TUI (serve.ts). Resume can't be an argv flag on serve; it has to plumb into session-creation:
Fork the driven session from the given id — via the opencode SDK (session.create from a parent) in the plugin, or by having the attach/create step use --session <id> --fork.
Store locality: the connector pins a fresh per-agent SQLite DB each spawn (<dataRoot>/.cotal/opencode/<name>/opencode.db) to avoid the global DB write-lock. A resume id lives in the operator's real opencode store (default HOME/XDG), so the fork must source the parent transcript from there into the per-agent DB. This is the one dimension claude doesn't have.
Acceptance
@cotal-ai/connector-opencodebuildLaunch({ resume }) renders a real fork (no longer throws); the driven session is forked from the given id and the original opencode session is unchanged afterward.
Fork-always holds: no path resumes without forking.
Follow-up to #23 (resume an existing session into the mesh). The session-resume plan ships claude resume first (
claude --resume <id> --fork-session) and has the opencode connector throw onresumefor now. This issue tracks lighting up opencode for real.The design already accommodates it
resumeis generic by construction, so opencode is a connector-internal change only — no core or CLI/manager/MCP changes:LaunchOpts.resume?: string— "a prior-session id to fork from" — which is exactly what opencode needs too (opencode run/attach --session <id> --fork, same fork-never-reuse contract as claude's--fork-session).cotal spawn --resume,cotal start --resume, MCPcotal_spawn(resume=…)) forward the string connector-agnostically.@cotal-ai/connector-opencode: replace thebuildLaunchthrow with real rendering.Why it was deferred (the actual work)
Unlike claude (a pure argv flag), the opencode connector runs a headless
opencode serve+ an in-process plugin that creates the ONE session it drives, then attaches a viewer TUI (serve.ts). Resume can't be an argv flag onserve; it has to plumb into session-creation:session.createfrom a parent) in the plugin, or by having the attach/create step use--session <id> --fork.<dataRoot>/.cotal/opencode/<name>/opencode.db) to avoid the global DB write-lock. A resume id lives in the operator's real opencode store (default HOME/XDG), so the fork must source the parent transcript from there into the per-agent DB. This is the one dimension claude doesn't have.Acceptance
@cotal-ai/connector-opencodebuildLaunch({ resume })renders a real fork (no longer throws); the driven session is forked from the given id and the original opencode session is unchanged afterward.