[FEATURE]: Server Registry & Auto-Discovery for Persistent Sessions #6520

Open
opened 2026-02-16 18:04:27 -05:00 by yindo · 2 comments
Owner

Originally created by @velazcod on GitHub (Jan 16, 2026).

Originally assigned to: @thdxr on GitHub.

Feature hasn't been suggested before.

  • I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Problem
Currently, the opencode TUI command always spawns a new, isolated worker process that runs the backend logic. When the TUI exits, this worker is shut down, causing Instance.disposeAll() to trigger and abort all running agents/sessions.

This leads to two main issues:

  1. Agent Termination: Users cannot exit the TUI without killing background agents (unless they manually use opencode serve + opencode attach).
  2. Resource Duplication: If a user runs opencode serve for a project, running opencode in the same directory spawns a second parallel instance instead of connecting to the existing server.

Proposed Solution
Implement a Server Registry mechanism that allows opencode serve to advertise its presence and opencode (TUI) to automatically discover and connect to an existing server for the current working directory.

  1. Registry Storage: Use the existing Global.Path.state (e.g., ~/.local/state/opencode) to store server registration files.

  2. Server-Side Changes (opencode serve)

  • On Startup:
    1. Calculate SHA-256 hash of process.cwd().
    2. Write the registration JSON file to Global.Path.state/servers/.json.
  • On Shutdown:
    1. Delete the registration file to ensure clean state.
  1. Client-Side Changes (opencode TUI)
  • Before Spawning Worker:
    1. Calculate SHA-256 hash of the target project directory.
    2. Check if the corresponding JSON file exists in the registry.
    3. Validation: If it exists, check if the process pid is still running.
      • If stale: Delete the file and proceed to spawn a new worker.
      • If valid: Read the port and secret.
    4. Connection: Instead of spawning a new worker, enter "Attach Mode" (similar to opencode attach) using the discovered credentials.
    5. Exit Behavior: If attached to a discovered server, do not send the shutdown signal on exit.

Reason and Benefits

  • I am in the process of developing a mobile client for opencode and leveraging opencode serve for this. Implementing this feature would allow users to switch from remote and local session back and forth as needed, without their background processes dying when they exit from the TUI.
Originally created by @velazcod on GitHub (Jan 16, 2026). Originally assigned to: @thdxr on GitHub. ### Feature hasn't been suggested before. - [x] I have verified this feature I'm about to request hasn't been suggested before. ### Describe the enhancement you want to request **Problem** Currently, the opencode TUI command always spawns a new, isolated worker process that runs the backend logic. When the TUI exits, this worker is shut down, causing Instance.disposeAll() to trigger and abort all running agents/sessions. **This leads to two main issues:** 1. Agent Termination: Users cannot exit the TUI without killing background agents (unless they manually use opencode serve + opencode attach). 2. Resource Duplication: If a user runs opencode serve for a project, running opencode in the same directory spawns a second parallel instance instead of connecting to the existing server. **Proposed Solution** Implement a Server Registry mechanism that allows opencode serve to advertise its presence and opencode (TUI) to automatically discover and connect to an existing server for the current working directory. 1. Registry Storage: Use the existing `Global.Path.state` (e.g., `~/.local/state/opencode`) to store server registration files. 2. Server-Side Changes (opencode serve) - On Startup: 1. Calculate SHA-256 hash of process.cwd(). 2. Write the registration JSON file to Global.Path.state/servers/<hash>.json. - On Shutdown: 1. Delete the registration file to ensure clean state. 3. Client-Side Changes (opencode TUI) - Before Spawning Worker: 1. Calculate SHA-256 hash of the target project directory. 2. Check if the corresponding JSON file exists in the registry. 3. Validation: If it exists, check if the process pid is still running. - If stale: Delete the file and proceed to spawn a new worker. - If valid: Read the port and secret. 4. Connection: Instead of spawning a new worker, enter "Attach Mode" (similar to opencode attach) using the discovered credentials. 5. Exit Behavior: If attached to a discovered server, do not send the shutdown signal on exit. **Reason and Benefits** - I am in the process of developing a mobile client for opencode and leveraging `opencode serve` for this. Implementing this feature would allow users to switch from remote and local session back and forth as needed, without their background processes dying when they exit from the TUI.
yindo added the discussion label 2026-02-16 18:04:27 -05:00
Author
Owner

@github-actions[bot] commented on GitHub (Jan 16, 2026):

This issue might be a duplicate of existing issues. Please check:

  • #8890: [FEATURE]: Better support remote/server-client use-cases from the CLI - Proposes allowing attach to work with other commands and sessions
  • #7629: [Enhancement] Desktop app and terminal should connect to existing server instead of starting a new one when port is already in use - Addresses the core problem of multiple instances competing for the same port
  • #6461: [FEATURE]: Named Remote Connections with Session Origin Tracking - Comprehensive proposal for multi-environment workflows with automatic daemon lifecycle management and session origin tracking

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Jan 16, 2026): This issue might be a duplicate of existing issues. Please check: - #8890: [FEATURE]: Better support remote/server-client use-cases from the CLI - Proposes allowing attach to work with other commands and sessions - #7629: [Enhancement] Desktop app and terminal should connect to existing server instead of starting a new one when port is already in use - Addresses the core problem of multiple instances competing for the same port - #6461: [FEATURE]: Named Remote Connections with Session Origin Tracking - Comprehensive proposal for multi-environment workflows with automatic daemon lifecycle management and session origin tracking Feel free to ignore if none of these address your specific case.
Author
Owner

@velazcod commented on GitHub (Jan 17, 2026):

I don't think #6461 nor #7629 are exactly duplicates, but you could argue that #8990 is, albeit with a different approach of solving the issue and different use case.

@velazcod commented on GitHub (Jan 17, 2026): I don't think #6461 nor #7629 are exactly duplicates, but you could argue that #8990 is, albeit with a different approach of solving the issue and different use case.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#6520