acp: edits are written to disk directly instead of going through fs.writeTextFile, so native review UI never shows

[anthony-furman]

Description

When running opencode acp and connecting from an ACP client that advertises the fs.writeTextFile capability (e.g. Zed), edit/write tool calls still write straight to disk from OpenCode's own process instead of going through the client's fs/write_text_file. Two knock-on problems:

1. The client's native "Keep / Reject" review UI never appears for file edits, because the file is already mutated on disk by the time the client would show it. This is the same behavior already reported in acp, zed: does not support native changes review #4240.
2. For clients that do implement fs/write_text_file, OpenCode still fires that RPC in addition to its own direct write. So every approved edit produces two separate write signals for the same change: the tool call itself, and a separate fs/write_text_file request — even though only one of them is the operative write.

packages/opencode/src/acp/service.ts's initialize handler never reads or stores params.clientCapabilities.fs.writeTextFile, and packages/opencode/src/acp/permission.ts's writeProposedEdit fires connection.writeTextFile(...) unconditionally whenever an edit permission is approved, regardless of what the client declared. The tool itself (edit.ts/write.ts) always writes to its own disk via afs.writeWithDirs(...) right after, so there's no single source of truth for the mutation.

#4240 tracked this before and was closed when the ACP implementation was refactored/promoted (#29929), but the underlying capability-gating gap was never actually fixed in that refactor, it's still present on current dev.

Plugins

No response

OpenCode version

No response

Steps to reproduce

1. Run opencode acp and connect from Zed (or any ACP client implementing fs.writeTextFile).
2. Ask the agent to edit an existing file.
3. Approve the edit permission prompt.

Expected: the client's native inline diff review ("Keep"/"Reject") appears, and the client is the one applying the change.
Actual: the file is already written to disk directly by OpenCode's own process; no native review appears, and the client separately receives an fs/write_text_file request with the same final content.

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response