[Feature] OpenCode integration

[selfagency]

Summary

Add first-class OpenCode support to Termdock so OpenCode can be launched, tracked, resumed, and managed as a native AI coding workflow inside workspaces.

OpenCode is already a strong fit for Termdock’s AI-first terminal/workspace model, but today it appears to require manual terminal usage. A deeper integration would let Termdock manage OpenCode sessions the same way it manages other developer workflows.

Why this is valuable

• OpenCode is a terminal-native AI coding agent, so it aligns with Termdock’s terminal-centric UX.
• Termdock already emphasizes workspace switching, Git workflows, multi-tab terminals, and AI tool integration.
• Native OpenCode support would reduce context switching and make OpenCode more discoverable inside Termdock.
• It would make Termdock more compelling for users who want project-scoped AI sessions with persistent context.

Proposed Solution | 建議解決方案

1. OpenCode integration as a first-class session type

Model OpenCode as a dedicated session/workflow type, not just a generic shell command.

• Add an opencode session/template type in Termdock.
• Allow launching OpenCode from:
  • workspace actions
  • command palette / quick actions
  • terminal tabs
  • project context menus
• Preserve the current workspace/project path when launching OpenCode.

2. Workspace-aware OpenCode startup

OpenCode should launch with the current project context automatically.

• Detect the active workspace root.
• Start OpenCode in that directory.
• If the project has OpenCode-specific config files, surface them in the UI.
• If multiple workspaces are open, allow one OpenCode session per workspace.

Suggested behavior:

• OpenCode → Current workspace
• OpenCode → New session
• OpenCode → Resume last session for workspace

3. Session lifecycle management

Provide session tracking so OpenCode sessions behave like manageable Termdock resources.

• Track OpenCode process/session metadata:
  • workspace path
  • start time
  • last activity
  • command used to launch
  • session name or ID if available
• Add session actions:
  • launch
  • focus
  • restart
  • stop
  • resume
• Display session state in UI so users can distinguish:
  • running
  • idle
  • exited
  • reconnectable/resumable

4. Config detection and setup helpers

Termdock should help users configure OpenCode correctly.

• Detect common OpenCode config locations and project-local config files.
• Surface provider/API key setup requirements.
• Offer quick links or inline help when OpenCode dependencies are missing.
• Optionally add a “validate OpenCode setup” action that checks:
  • command availability
  • config presence
  • provider key availability
  • workspace path accessibility

5. Conversation/session persistence

If OpenCode supports persisted conversations or resumable sessions, Termdock should expose that cleanly.

• Store OpenCode session references per workspace.
• Allow reopening the most recent session for a project.
• Consider a lightweight session registry inside Termdock for:
  • workspace path
  • OpenCode session identifier
  • last run metadata
  • user-friendly label

If OpenCode exposes a structured history or conversation store, Termdock should integrate with it instead of inventing a separate source of truth.

6. UI/UX surface

Suggested UI additions:

• Workspace action: OpenCode
• Session action: Resume OpenCode
• Status badge for OpenCode sessions
• Dedicated OpenCode panel/tab grouping
• Recent OpenCode sessions list per workspace

Suggested command palette entries:

• OpenCode: Start in current workspace
• OpenCode: Resume last session
• OpenCode: Open config
• OpenCode: Validate installation

Implementation details

Backend/process layer

• Introduce an OpenCode runner abstraction in the process/session manager.
• Support a configurable launch command, e.g.:
  • opencode
  • npx opencode
  • custom binary path
• Ensure the process manager can:
  • spawn OpenCode with workspace cwd
  • stream stdout/stderr
  • detect exit codes
  • reconnect to a previous session when possible

Data model

Proposed session metadata:

{
  "type": "opencode",
  "workspacePath": "/path/to/project",
  "launchCommand": "opencode",
  "sessionId": "optional-provider-session-id",
  "displayName": "Project AI Session",
  "status": "running",
  "lastActivityAt": "2026-06-12T14:22:00Z",
  "createdAt": "2026-06-12T13:55:00Z"
}

Discovery logic

• Check whether opencode is installed and executable.
• Support custom executable paths.
• Detect common install methods if helpful, but keep the primary path simple and explicit.
• Surface a clear error if launch fails:
  • command not found
  • missing provider auth
  • invalid config
  • incompatible workspace path

Extensibility

Design this so similar AI CLI tools can be added later using the same session abstraction.

Non-goals

• Do not make OpenCode support depend on a single provider.
• Do not hardcode provider credentials into Termdock.
• Do not require users to manage OpenCode only through Termdock.
• Do not build a separate AI chat system unless it is needed to support OpenCode session lifecycle.

Acceptance criteria

• OpenCode can be launched from a workspace inside Termdock.
• OpenCode sessions are visible and manageable in the UI.
• Users can resume or relaunch the most recent OpenCode session for a workspace.
• Termdock detects and reports missing OpenCode prerequisites clearly.
• OpenCode works across multiple workspaces without overwriting session context.
• Documentation is updated with recommended setup and troubleshooting steps.

Optional enhancements

• Support OpenCode launch presets per workspace.
• Add a “recent OpenCode sessions” section.
• Surface OpenCode config status in workspace details.
• Integrate with Git/worktree flows so each branch/worktree can have its own OpenCode session.
• Add keyboard shortcuts for start/resume/stop.

Alternatives Considered | 考慮的替代方案

No response

Priority | 優先級

High - Essential for my use case | 高 - 對我的使用情況至關重要

Implementation | 實作

• I'd be willing to help implement this feature | 我願意協助實作這個功能
• I can provide detailed requirements/specifications | 我可以提供詳細需求/規格說明
• I can help with testing | 我可以協助測試

Additional Context | 額外資訊

No response

[cyh7789]

Thanks for the detailed proposal! We've reviewed this and will be implementing OpenCode as Termdock's fourth first-class agent session provider.

After analyzing the OpenCode 2.0 source, we found that it uses a daemon + HTTP server + TUI client architecture (REST API + SSE event streaming), which is fundamentally different from the spawn + JSON stdout pattern used by Codex/Gemini. This actually gives us a much cleaner integration path than the stdout/stderr streaming approach described in the issue.

Our plan covers two integration paths:

1. HTTP API (programmatic dispatch) — A new OpenCodeHttpAgentSessionProvider that talks to the OpenCode daemon via REST API + SSE. This provides structured session management with proper event mapping (tool calls, token usage, session state) without any output parsing.

2. Interactive terminal (TUI) — An OpenCodeInteractiveTerminalSessionProvider for users who want to operate the OpenCode TUI directly inside Termdock, following the same pattern as our Claude/Codex/Gemini interactive providers.

Most of the requirements you listed (session lifecycle, workspace-aware startup, persistence/resume, UI surface) are already handled by Termdock's existing AgentSessionService infrastructure — adding opencode as a provider automatically gets those capabilities. The genuinely new work is the daemon client (HTTP + SSE + auth), the two providers, and config detection/validation.

We'll schedule this for implementation. A technical spec has been written internally.