Concerns regarding the removal of client filesystem and terminal capabilities

[Ruddickmg]

I would like to open a discussion regarding the proposed removal of the client filesystem and terminal capabilities in the v2 specification (as outlined in RFD v2: Client Filesystem & Terminal Capabilities).

While streamlining the protocol is an understandable goal, completely removing these capabilities introduces severe limitations for common development environments and remote workflows. Since this functionality is already optional, keeping it in the spec costs nothing, whereas removing it forces complex, sub-optimal workarounds onto clients.

Here is a breakdown of why preserving these capabilities is critical for the versatility and adoption of the Agent Client Protocol (ACP).

Core Arguments Against Removal:

1. Breaks Remote and Containerized Use Cases
   Removing client-side filesystem and terminal capabilities effectively makes remote usage impossible. It forces the agent to run on the exact same physical machine as the host. If a user is connecting to a remote server, container, or cloud development environment, the agent will no longer be able to read/edit files or interact with the terminal.
2. Permissions Mismatch and IDE Disconnect
   Bypassing the client breaks the security and permission model. When the agent interacts directly via the client, it inherits the permissions, configuration, and security context already established by the IDE or client. Shifting this entirely away from the client creates a disjointed security model.
3. Unnecessary Architecture Burden via MCP
   Offloading this functionality adds unnecessary burden to clients, who now have to implement and route everything through the Model Context Protocol (MCP). Instead of leveraging a unified ACP interface, clients must manage a more fragmented tool stack to achieve the same result.
4. State Syncing and Tracking Limitations
   • Change Tracking: Moving these capabilities out of the client limits the client’s ability to track, audit, or undo changes made by the agent within the active editor session.
   • Unsaved Buffers: Many widely used editors (like Vim) do not automatically save every keystroke or buffer to the filesystem. If the agent operates purely on the filesystem, it cannot see live, unsaved changes made by the user in the client, leading to race conditions or stale contexts.
   • Complex Update Triggers: To reflect agent-driven changes back into a running IDE or editor, the client would be forced to constantly poll or watch the filesystem for changes, significantly increasing implementation complexity.
5. High Value, Low Cost
   The primary argument for removal seems to be slow adoption, but slow adoption does not equate to a lack of value. Leaving these capabilities as optional components of the spec should cost very little from a maintenance standpoint. Existing implementations will still need to maintain backwards compatibility anyway.

Taking ubiquitous editors like Vim into account, the limitations introduced by this removal are significant. Keeping these capabilities optional leaves the door open for advanced, remote, and buffer-aware workflows that would otherwise be impossible or overly complex to implement at the client level.

I hope the maintainers will consider retaining the client filesystem and terminal integration and capabilities as optional features in the v2 specification rather than removing them entirely.

[benbrandt]

The decision was made by two factors:

1. Very little client support in the major vendors (most didn't implement)
2. Very little agent usage. Most agents have their own ways to access the filesystem and terminals, and didn't rely on the ones provided by ACP anyway. So even if the client implemented it, most agents, who needed their own access in case a client didn't provide this anyway, never implemented things twice.

I can see you got value out of this. But the fact is no one was using this APIs anyway.