-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Description
Describe the feature or problem you'd like to solve
When connecting to Copilot CLI via ACP from an editor (e.g., Neovim using agentic.nvim), each copilot --acp --stdio invocation spawns an independent process with its own session state. There's no way to connect an ACP client to an existing session running in another process — such as a terminal session already in progress. Copilot already advertises loadSession: true and sessionCapabilities: { list: {} } during ACP initialize, but these only operate within the same process. Sessions are process-local, so session/list from a newly spawned ACP instance returns nothing useful — it can't see sessions from the terminal CLI or other ACP connections. This means if I'm working with Copilot in my terminal and want to continue that same conversation from my editor (or vice versa), I can't. Each client gets a completely independent context with no shared history.
Proposed solution
Implement a session persistence layer that allows session/list and session/load to work across process boundaries. Options:
-
Session daemon — A persistent background process that holds session state, with both terminal CLI and ACP clients connecting to it as frontends. Similar to how SageFs/FSI maintains a single worker process that multiple clients attach to.
-
Shared session store — Persist session state (conversation history, context, tool permissions) to disk (e.g.,
~/.copilot/session-state/), and allowsession/loadfrom any ACP process to hydrate from that store. The JSONL session files already exist — this would make them loadable by ACP clients. -
Named sessions — Allow
copilot --acp --stdio --session <id>to attach to (or create) a named session backed by persistent storage, so multiple processes can share the same conversation.
Example prompts or workflows
# Terminal: start working on a feature
copilot... have a conversation, Copilot understands the codebase context ...
Editor: open Neovim, connect agentic.nvim to the SAME session
Instead of getting a blank session, it picks up where the terminal left off
Both clients see the same conversation history and tool permissions
Additional context
- Verified by testing the ACP protocol directly: initialize → session/new → session/prompt all work correctly between Copilot CLI v0.0.420 and agentic.nvim
- session/list returns empty results from a fresh process even when other Copilot sessions are actively running
- The ACP spec already has the right primitives (loadSession, session/list, session/load) — the implementation just needs cross-process backing
- This would also benefit the /ide command flow, which currently can only push context one-way from CLI to a connected IDE