What happened
When OpenCode runs as an ACP server via opencode acp, read tool results appear to be emitted to ACP clients with a presentation-oriented envelope and inline line-number prefixes.
Observed in an Agent of Empires web dashboard cockpit session using OpenCode 1.15.13 with gpt-5.5:
<path>/Users/seluj78/aoe/agent-of-empires-worktrees/Koreans/web/src/lib/sidebarGroups.ts</path>
<type>file</type>
<content>
1: import type { RepoColor } from "./repoAppearance";
2: import type {
3: RepoGroup,
4: SessionResponse,
5: Workspace,
6: WorkspaceStatus,
7: } from "./types";
That text is useful for model context, but it is not ideal as ACP tool-result content for structured clients. A client that already renders a dedicated read card has a file path in the tool metadata and can render its own line-number gutter or range metadata. Receiving <path>, <type>, <content>, and N: prefixes in the result body makes the structured UI look like it is showing raw transport text instead of a file preview.
Expected behavior
For ACP read tool updates, the result content should prefer the raw file body, with path, type, range, and line metadata carried as structured fields where ACP supports it. If OpenCode needs numbered context internally, that formatting should stay inside OpenCode's prompt/model context layer rather than being emitted as the user-visible ACP tool result body.
Why this looks upstream
Agent of Empires checked its side of the ACP path:
- AoE's
fs/read_text_file handler returns raw file text through ReadTextFileResponse::new(sliced). It does not add <path>, <type>, <content>, or N: prefixes.
- AoE stores ACP
ToolCallUpdate.fields.content text verbatim in ToolCallCompleted.content.
- The web cockpit read card was rendering that verbatim result text.
So the wrapper appears to be introduced by OpenCode's ACP/tool-result layer, not by the ACP client.
Reproduction context
Request
Please emit clean ACP read result content, or expose structured read result metadata separately from the display text, so ACP clients can render read cards without stripping OpenCode-specific wrappers.
What happened
When OpenCode runs as an ACP server via
opencode acp, read tool results appear to be emitted to ACP clients with a presentation-oriented envelope and inline line-number prefixes.Observed in an Agent of Empires web dashboard cockpit session using OpenCode
1.15.13withgpt-5.5:That text is useful for model context, but it is not ideal as ACP tool-result content for structured clients. A client that already renders a dedicated read card has a file path in the tool metadata and can render its own line-number gutter or range metadata. Receiving
<path>,<type>,<content>, andN:prefixes in the result body makes the structured UI look like it is showing raw transport text instead of a file preview.Expected behavior
For ACP read tool updates, the result content should prefer the raw file body, with path, type, range, and line metadata carried as structured fields where ACP supports it. If OpenCode needs numbered context internally, that formatting should stay inside OpenCode's prompt/model context layer rather than being emitted as the user-visible ACP tool result body.
Why this looks upstream
Agent of Empires checked its side of the ACP path:
fs/read_text_filehandler returns raw file text throughReadTextFileResponse::new(sliced). It does not add<path>,<type>,<content>, orN:prefixes.ToolCallUpdate.fields.contenttext verbatim inToolCallCompleted.content.So the wrapper appears to be introduced by OpenCode's ACP/tool-result layer, not by the ACP client.
Reproduction context
1.15.13opencode acpgpt-5.5Request
Please emit clean ACP read result content, or expose structured read result metadata separately from the display text, so ACP clients can render read cards without stripping OpenCode-specific wrappers.