RFD: Multi-Client Session Attach#533
Open
joaommartins wants to merge 2 commits intoagentclientprotocol:mainfrom
Open
RFD: Multi-Client Session Attach#533joaommartins wants to merge 2 commits intoagentclientprotocol:mainfrom
joaommartins wants to merge 2 commits intoagentclientprotocol:mainfrom
Conversation
Proposes session/attach method to allow multiple ACP clients to connect to and interact with the same live agent session simultaneously. Key features: - Controller/observer client roles - First-writer-wins permission routing - Proxy-based architecture (builds on proxy-chains RFD) - WebSocket/SSE transport for multi-client support This enables unified notification dashboards, pair programming with agents, cross-device continuity, and graceful client recovery without requiring changes to existing agents.
Address review feedback on the initial RFD draft:
- Add status: "proposal" to frontmatter
- Add historyPolicy parameter (full/pending_only/none) to session/attach,
giving lightweight clients control over history replay on connect
- Document historyPolicy effect on the history field in the response
- Add error response examples for session/attach failure cases
(session not found, not authorised, capability absent)
- Add session/detach success response example
- Remove maxClients from core proposal; defer to Shiny Future as a
possible later capability for operators to cap concurrent connections
- Fix observer role description to mention future session/promote path
- Renumber error codes to remove gap left by removed maxClients error
- Fix implementation plan wording ("with a `roles` field")
|
I have a use case for this and found this issue because I was considering building the same thing: I've been building (WIP, I can't guarantee it's safe at the moment) github.com/ElleNajt/agent-to-go , where the idea is that I forward claude code terminal sessions via tmux/ttyd/tailscale to my phone. There are similar projects, but I'm trying to build something minimal that just provides easily auditable glue interacting with and and managing coding agent CLIs on the phone -- and multiplexing an ACP session between a mobile friendly ACP front end and whatever ACP front end is on the dev machine is ideal for this. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This RFD proposes a
session/attachmethod that allows multiple ACP clients to connect to and interact with the same live agent session simultaneously — enabling a unified notification and approval UI across concurrent coding agent workflows.Key features
request_permissionis broadcast to all controllers; the first response wins and all clients are notified viapermission_resolvedhistoryPolicyparameter — Clients control history replay on attach:full(default),pending_only, ornonesession/detachlets clients leave voluntarily; the session continues as long as one controller remainsProblem
ACP currently assumes a 1:1 relationship between a client and an agent session. For developers running multiple concurrent agent sessions (Claude Code, Codex, Gemini, etc.), this creates a significant context-switching tax:
session/loadsupports sequential handoff only — not concurrent access to a live sessionExample
{ "jsonrpc": "2.0", "id": 5, "method": "session/attach", "params": { "sessionId": "sess_abc123def456", "role": "controller", "historyPolicy": "pending_only", "clientInfo": { "name": "notification-dashboard", "version": "1.0.0" } } }Capability negotiation
{ "agentCapabilities": { "sessionCapabilities": { "attach": { "roles": ["controller", "observer"] } } } }Relationship to existing RFDs
This proposal builds directly on the Agent Extensions via ACP Proxies RFD — the proxy architecture established there is the recommended implementation pattern for multi-client attach. It also depends on Session List for session discovery and complements Resuming of existing sessions.