-
Notifications
You must be signed in to change notification settings - Fork 160
Added remote-session-support.mdx.mdx #442
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
anna239
wants to merge
2
commits into
main
Choose a base branch
from
anna.zhdan/rfd-remote-schema
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,167 @@ | ||
| --- | ||
| title: "Remote Session Support" | ||
| --- | ||
|
|
||
| - Author(s): [@anna239](https://github.com/anna239) | ||
|
|
||
| ## Elevator pitch | ||
|
|
||
| > What are you proposing to change? | ||
|
|
||
| Add first-class support for remote agent execution by extending `session/new` request and response with git repository information. This enables agents to execute work on remote servers, make changes to the codebase, and return a branch reference that clients can fetch and merge. | ||
|
|
||
| ## Scope | ||
|
|
||
| This RFD focuses exclusively on the **data types and schema changes** required for remote session support. | ||
|
|
||
| **Explicitly out of scope:** | ||
|
|
||
| - Authentication mechanisms (OAuth, tokens, API keys, etc.) | ||
| - Transport protocols (WebSocket vs HTTP) | ||
| - Connection management and lifecycle | ||
| - Server-side implementation details | ||
|
|
||
| These concerns will be addressed in separate RFDs. | ||
|
|
||
| ## Status quo | ||
|
|
||
| > How do things work today and what problems does this cause? Why would we change things? | ||
|
|
||
| Currently, ACP sessions assume the agent runs locally alongside the client, with direct filesystem access. The agent can read and write files in the user's working directory. | ||
|
|
||
| ## Shiny future | ||
|
|
||
| > How will things play out once this feature exists? | ||
|
|
||
| Clients will be able to send repository context when creating sessions, and agents will return branch references when work is complete. This enables: | ||
|
|
||
| 1. **Cloud-hosted agents** that clone repositories, do work, and push results | ||
| 2. **IDE integration** where the client fetches the result branch and presents merge options | ||
|
|
||
| The typical flow becomes: | ||
|
|
||
| 1. Client sends `session/new` with `remote` containing repository URL, branch, and revision | ||
| 2. Agent clones/fetches the repo, checks out the revision | ||
| 3. Agent performs requested work | ||
| 4. Agent pushes changes to a new branch | ||
| 5. Agent returns `session/prompt` response with `target` containing the result branch info | ||
| 6. Client fetches the branch and allows user to review/merge | ||
|
|
||
| ## Implementation details and plan | ||
|
|
||
| > Tell me more about your implementation. What is your detailed implementation plan? | ||
|
|
||
| ### New Types | ||
|
|
||
| #### RemoteRef | ||
|
|
||
| A discriminated union type representing a reference to remote storage. The `type` field determines the variant: | ||
|
|
||
| ```typescript | ||
| type RemoteRef = GitRemoteRef; // Future: | SomeOtherRemoteRef | ... | ||
| ``` | ||
|
|
||
| #### GitRemoteRef | ||
|
|
||
| A git-based remote reference. This is currently the only implementation of `RemoteRef`: | ||
|
|
||
| ```typescript | ||
| interface GitRemoteRef { | ||
| /** Discriminator for the remote type */ | ||
| type: "git"; | ||
|
|
||
| /** Git remote URL (SSH or HTTPS format) */ | ||
| url: string; | ||
|
|
||
| /** Branch name (e.g., "main", "feature/xyz") */ | ||
| branch: string; | ||
|
|
||
| /** Full commit SHA */ | ||
| revision: string; | ||
| } | ||
| ``` | ||
|
|
||
| ### Schema Changes | ||
|
|
||
| #### NewSessionRequest | ||
|
|
||
| Add optional `remote` field to `NewSessionRequest`: | ||
|
|
||
| ```typescript | ||
| interface NewSessionRequest { | ||
| /** Current working directory (existing) */ | ||
| cwd: string; | ||
|
|
||
| /** MCP servers to connect (existing) */ | ||
| mcpServers: McpServer[]; | ||
|
|
||
| /** | ||
| * Remote storage reference for remote execution. | ||
| * When present, indicates the client wants the agent to work on | ||
| * this remote source rather than using local filesystem access. | ||
| */ | ||
| remote?: RemoteRef; | ||
|
|
||
| /** Extension metadata (existing) */ | ||
| _meta?: Record<string, unknown>; | ||
| } | ||
| ``` | ||
|
|
||
| #### PromptResponse | ||
|
|
||
| Add optional `target` field to `SessionPromptResponse`: | ||
|
|
||
| ```typescript | ||
| interface PromptResponse { | ||
| target?: RemoteRef; | ||
|
|
||
| stopReason: StopReason; | ||
|
|
||
| /** Extension metadata (existing) */ | ||
| _meta?: Record<string, unknown>; | ||
| } | ||
| ``` | ||
|
|
||
| ### JSON Schema Additions | ||
|
|
||
| ```json | ||
| { | ||
| "$defs": { | ||
| "RemoteRef": { | ||
| "description": "A reference to remote storage. Discriminated by the 'type' field.", | ||
| "oneOf": [{ "$ref": "#/$defs/GitRemoteRef" }] | ||
| }, | ||
| "GitRemoteRef": { | ||
| "description": "A git-based remote reference.", | ||
| "properties": { | ||
| "type": { | ||
| "const": "git", | ||
| "description": "Discriminator indicating this is a git reference" | ||
| }, | ||
| "url": { | ||
| "type": "string", | ||
| "description": "Git remote URL" | ||
| }, | ||
| "branch": { | ||
| "type": "string", | ||
| "description": "Branch name" | ||
| }, | ||
| "revision": { | ||
| "type": "string", | ||
| "description": "Full commit SHA (40 character hex string)" | ||
| } | ||
| }, | ||
| "required": ["type", "url", "branch", "revision"], | ||
| "type": "object" | ||
| } | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| ## Frequently asked questions | ||
|
|
||
| > What questions have arisen over the course of authoring this document? | ||
|
|
||
| ## Revision history | ||
|
|
||
| - 2026-02-02: Initial draft | ||
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I understand correctly: this is more about which code the agent should be working on?
Is the code in the
cwd, or will it have to fetch it?In this scenario, is it important that the agent knows what to do with this information? Or will there be something in between?
If the agent should, then I guess we need some capabilities. If not, then I wonder if this is somehow better handled by the proxy RFD where something gets a cwd ready for the agent session before calling session/new for the agent?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Basically, I am trying to understand whose responsibility it is to set this thing up which will help me better grasp how this should fit in the protocol
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I.e. should this be here? Another method? somewhere else? etc.