Skip to content

docs(rfd): client-owned fs/apply_patch#808

Open
leovigna wants to merge 1 commit intoagentclientprotocol:mainfrom
leto-labs:rfds/fs-apply-patch
Open

docs(rfd): client-owned fs/apply_patch#808
leovigna wants to merge 1 commit intoagentclientprotocol:mainfrom
leto-labs:rfds/fs-apply-patch

Conversation

@leovigna
Copy link

Summary

This adds an initial RFD draft for a client-owned fs/apply_patch capability.

The draft proposes:

  • a new client capability under clientCapabilities.fs.applyPatch
  • a new client-owned method, fs/apply_patch
  • applying structured multi-file edits against the client's live editor-backed document state, including unsaved buffers
  • treating tool-call diff content as presentation/reporting, not as a mutation API
  • using a V4A-style apply_patch envelope as the initial default format, profiled for ACP semantics such as absolute paths

Why

ACP already has client-owned file access via fs/read_text_file and fs/write_text_file, but it does not yet have a client-owned mutation method for structured patch-style edits against current buffer state.

That gap matters for coding agents that want precise multi-file edits without falling back to whole-file overwrite.

Open questions

The draft calls out a few areas to iterate on next:

  • the exact ACP profile of the V4A-style grammar
  • how preconditions should work in v1
  • whether the patch field should stay a string envelope or become a richer object
  • whether transactional semantics should be required initially

This is intended as an early draft for discussion rather than a finalized wire shape.

Add an initial RFD draft for a client-owned patch-application capability under the filesystem surface.

The proposal introduces fs/apply_patch as a client capability-backed mutation method for applying structured multi-file edits against the client’s current editor-backed document state, including unsaved buffers.

The draft explicitly distinguishes ACP tool-call diff content from client-owned mutation APIs, recommends a boolean fs.applyPatch capability to stay aligned with the existing filesystem capability model, and frames patch application as client-owned so editors can preserve undo/redo, diagnostics, formatting, save lifecycle, and conflict handling.

It also proposes starting from the publicly documented V4A-style apply_patch grammar used in Codex-style workflows as the initial default format, while profiling it for ACP semantics such as absolute paths and live-buffer application rather than direct disk mutation.

The RFD includes a first-pass method sketch, failure and atomicity discussion, and a set of open questions for follow-up iteration.
@leovigna leovigna changed the title RFD: client-owned fs/apply_patch docs(rfd): client-owned fs/apply_patch Mar 21, 2026
@leovigna leovigna marked this pull request as ready for review March 21, 2026 15:36
@leovigna leovigna requested a review from a team as a code owner March 21, 2026 15:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant