-
-
Notifications
You must be signed in to change notification settings - Fork 8
[FEATURE] Support termly connecting to existing opencode session #33
Description
Feature Description
A new command or flag within termly-cli that allows users to attach to, resume, or bridge into an already active opencode session. This would enable termly to manage and interact with sessions that were started outside of its own initialization flow.
Problem it Solves
I'm always frustrated when I have an active development environment running via opencode, but I have to terminate it and restart a fresh session through termly just to access the CLI's specialized management features.
Currently, there is a "silo" effect:
- Loss of State: Restarting a session means losing shell history, running background processes, and editor buffers.
- Manual Overhead: Users have to manually track session IDs and jump between tools rather than having termly act as the single source of truth for terminal management.
Proposed Solution
Introduce a connect or attach subcommand to the CLI:
termly connect [session_id | alias]
Key requirements:
- Discovery: If no ID is provided, termly should scan for active opencode sessions and provide an interactive picker.
- Synchronization: Upon connecting, termly should inject its environment wrappers (logging, aliases, etc.) into the existing shell without disrupting the primary process.
- Re-attachability: If the CLI connection drops, the opencode session should remain alive for a subsequent termly connect call.
Alternatives Considered
- Manual SSH/Attach: Manually finding the PID or container ID of the opencode session and attaching via standard shell tools. This is tedious and misses the specialized environment configurations termly provides.
- Always-on Termly: Starting every single task through termly from the beginning, which isn't always possible if a session was triggered by an automated script or another developer.
Use Case
A developer is working on a remote server and their local terminal crashes. The opencode session is still running fine on the remote host. Instead of calling termly start (which might provision a brand new environment), the developer calls termly connect to instantly jump back into their exact previous workspace with all their tools ready.
Additional Context
$ termly connect
Searching for active opencode sessions...
[1] project-alpha (ID: 8829) - Started 2h ago
[2] hotfix-db (ID: 1042) - Started 5m ago
Select session to connect: 1
Connecting to project-alpha...
Environment synced. Welcome back!
Implementation Ideas
- Socket Discovery: Use opencode's internal socket or API to query active session UUIDs.
- Namespace Attachment: For containerized sessions, use the exec or attach API to enter the existing namespace.
- Signal Handling: Implement logic to ensure that exiting the termly CLI wrapper sends a "detach" signal rather than a "terminate" signal to the underlying opencode process.