[Bug] buzz-acp agents can still publish literal \n after #2121

[marcusquinn]

Describe the bug

A managed OpenCode ACP agent can publish multiline replies containing literal backslash-n sequences (for example, \n\n) instead of real newline bytes. Buzz Desktop then correctly renders those characters literally.

PR #2121 added prompt guidance telling ACP agents to use stdin and warning that quoted \n is published literally. The failure still occurs in Buzz Desktop 0.5.5, so the guidance-only mitigation is not reliable for every ACP runtime or turn.

Steps to reproduce

1. Configure a managed OpenCode agent with the ACP command opencode acp.
2. Mention the agent in a channel and request a response containing multiple paragraphs or list items.
3. Let the agent publish its response through buzz messages send.
4. Inspect the resulting channel message and its relay event content.

Actual result: some replies display literal \n\n; the relay event already contains backslash and n characters rather than newline bytes.

Expected behavior

ACP-published multiline replies should contain real newline bytes and render as separate paragraphs or lines.

The fix should preserve intentional backslashes in code and prose. A global client-side unescape would therefore be unsafe. A harness/CLI-side validation, structured publishing path, or another deterministic safeguard may be more reliable than prompt guidance alone.

Version and platform

• Buzz Desktop: 0.5.5
• OS: macOS
• ACP runtime: OpenCode via opencode acp

Logs / additional context

Sanitized runtime evidence confirms the managed agent launched through opencode acp, connected to the relay, and reached online presence before publishing the affected response.

Source inspection indicates the literal characters exist before rendering:

• crates/buzz-cli/src/commands/messages.rs forwards supplied message content without converting escaped sequences.
• crates/buzz-sdk/src/builders.rs stores that content directly in the event.
• desktop/src/features/messages/lib/formatTimelineMessages.ts passes event content into the rendered message body.
• desktop/src/shared/ui/markdown/nodeCache.ts correctly handles real newline bytes through the Markdown pipeline.
• crates/buzz-acp/src/base_prompt.md documents the stdin workaround added by fix(acp): teach agents to send real newlines #2121.

This appears to be a recurrence or incomplete mitigation of the behavior addressed by #2121, rather than a Markdown rendering defect.

---

aidevops.sh v3.32.226 plugin for OpenCode v1.18.9 with gpt-5.6-sol

[Tony-ooo]

Independent reproduction on Buzz Desktop 0.5.5 / macOS with a managed ACP agent:

• The published event contained literal \\n\\n bytes, so Desktop displayed one visual line with visible \\n tokens.

• Re-publishing the same Markdown with real newline bytes produced the expected paragraphs, list spacing, and GFM table rendering.

• The safe producer command was:

  printf 'first paragraph\n\n- item\n\nsecond paragraph\n' \
    | buzz messages send --channel "$CHANNEL_ID" --content -

• The failing pattern was passing text containing \\n as an argument to printf '%s', which preserves those two literal characters before buzz messages send reads stdin.

I agree that Desktop must not globally decode \\n: this would change intentional examples in inline code, fenced code, JSON, shell, regex, and prose. The useful robustness improvement is upstream of the renderer: have the managed-agent/CLI publishing path detect likely accidental escaped multiline Markdown and either emit a non-sensitive warning/telemetry or use a structured content path. A regression should assert both cases: real newline bytes render as blocks, while intentional literal \\n remains verbatim.

This is therefore additional evidence for #4891 rather than a new rendering issue.