Transcript wrapper leakage still appears on v1.18.0 (system-reminder / thinking / tool_exec / tool_output / H:A wrappers)

[disolaterX]

Summary

There is still a transcript-leakage class on current upstream main / v1.18.0 that is distinct from the earlier raw tool_use text and block-index issues.

The proxy can still surface internal orchestration / transcript wrapper text into model-visible content, for example:

• <system-reminder> ... </system-reminder>
• <task_metadata> ... </task_metadata>
• <thinking> ... </thinking>
• leaked <tool_exec ...> / <tool_output ...> wrappers
• <!-- OMO_INTERNAL_INITIATOR -->
• H: / A: transcript prefixes
• ⚙ background_output [task_id=...]

When these leak into prompt reconstruction or forwarded text, Claude can start echoing them back as normal conversation text.

Example symptom

Things like this show up in assistant-visible output instead of being treated as internal transcript/control formatting:

Thinking: The user wants me to handle the case...
Tool Use: read({...})
H: [Tool Result for toolu_...: ...]
A: <tool_exec name="bash" />
<system-reminder>...</system-reminder>

This is very similar in user impact to #94 and #106, but the currently leaked shapes are broader than raw [Tool Use: ...] text alone.

What I checked

• v1.18.0 upstream server.ts still has no transcript sanitizer for these wrapper forms
• Earlier issues/PRs I checked:
  • Tool call leakage: raw tool_use blocks appear as text instead of being executed #94 raw tool_use leakage
  • sytem prompts showing in the context, like someone speacking to himself #106 talking-to-itself / system prompt leakage
  • Missing tools usage and output #153 missing tools usage/output
  • fix: remap block indices across multi-turn streaming responses #159 block index remapping

Those fixes help adjacent problems, but they do not seem to strip these specific wrapper patterns before they become model/user-visible.

Suggested direction

A small, targeted sanitizer at the proxy boundary for text-only content paths (prompt reconstruction + streamed/non-stream text forwarding), stripping only internal transcript wrappers while preserving real tool semantics.

Patterns that seemed necessary in local testing:

• <system-reminder>[\\s\\S]*?</system-reminder>
• <task_metadata>[\\s\\S]*?</task_metadata>
• <thinking>[\\s\\S]*?</thinking>
• <tool_output\\b[^>]*>[\\s\\S]*?</tool_output>
• <tool_exec\\b[^>]*\\/> and paired form
• <!-- OMO_INTERNAL_INITIATOR -->
• \\[SYSTEM DIRECTIVE: OH-MY-OPENCODE[^\\]]*\\]
• ⚙ background_output [task_id=...]
• stray H: / A: wrapper prefixes

Why this matters

These wrappers are orchestration/debug transcript artifacts, not semantic content Claude needs. If they enter normal conversation text, they can confuse the model and create the impression that it is "talking to itself" again.

If useful, I can provide a minimal patch shape that only addresses these wrapper leaks without changing broader session/model logic.

[rynfar]

Yes great findings. If you want to put together a fix i would be happy to review it and test it. Thank you!

[rynfar]

Thanks for the detailed write-up — the pattern catalog and the cross-references to earlier issues are helpful.

I dug into the content paths and I think there are three distinct sources getting conflated here:

1. oh-my-opencode artifacts — <!-- OMO_INTERNAL_INITIATOR -->, [SYSTEM DIRECTIVE: OH-MY-OPENCODE...], and ⚙ background_output [task_id=...] are injected by the oh-my-opencode plugin, not by the proxy. These should be cleaned up at the plugin layer, not stripped by the proxy after the fact.

2. Proxy prompt reconstruction format — H: / A: (from Human: / Assistant:) and [Tool Use: ...] / [Tool Result: ...] are the proxy's intentional prompt format used in buildFreshPrompt() for stale session retries. If the SDK echoes these back, the fix is to improve the prompt format itself, not to regex them out of responses.

3. SDK internal formatting — <system-reminder>, <task_metadata>, <tool_exec>, <tool_output> would come from the Claude Agent SDK's internal responses. If the SDK is leaking these into text blocks, that's an SDK-level issue.

Before we decide on a fix, could you help narrow this down?

• Can you reproduce this with vanilla OpenCode (no oh-my-opencode)? That would confirm whether this is a proxy issue or a plugin issue.
• When it happens, is it on a fresh session or after a stale session retry? (The proxy logs [PROXY] Stale session UUID, evicting and retrying as fresh session when a retry occurs — that's the path where Human: / Assistant: formatting is used.)

I don't want to add a broad regex sanitizer to the proxy — it would be fragile (breaks when the SDK changes formatting), prone to false positives (code blocks and markdown that happen to contain these patterns), and half the patterns aren't the proxy's to clean up. If there's a real proxy-layer bug here, I'd rather fix it at the specific content path where leakage occurs.

Happy to dig deeper once we have a reproduction to work with.