Repository navigation
Tool calls emit raw XML tags as text; write() reports success but file is never created (v2.0.31, Windows 11) #56204
Description
Describe the bug
Two related failures in the same long-running agent session (many tool calls):
1. Tool calls serialize incorrectly — raw XML tags leak as literal text
Model-emitted tool calls are not parsed cleanly. The raw parameter tags (the closing "parameter" and "invoke" tags) appear as literal text in the conversation output instead of being consumed as a tool call. Observed on read and shell calls. Sometimes the actual tool result is correct but wrapped in garbage; sometimes the output truncates mid-stream.
Ironically, this bug reproduced WHILE drafting this report: a write call containing the literal tag strings failed to parse as JSON and was never executed.
2. write reports success but the file is never created (critical)
A write call was issued to create backend/migrations/versions/0024_business_active_on_register.py. The tool returned:
{"path":"C:\\...\\0024_business_active_on_register.py","bytesWritten":122,"success":true}
Immediately afterward, Test-Path on that exact path returned False, and a directory listing of backend/migrations/versions/ ends at 0023_reconcile_schema.py. The file was never written to disk despite the success response.
To reproduce
- Run a long agent session with many tool calls (reads, shell, writes).
- Observe tool calls emitting raw closing parameter/invoke tags as text in the output.
- Issue a
writetool call — it returnssuccess:truewith a plausible byte count. - Verify the file exists (
Test-Path/ directory listing) — it does not.
Expected behavior
- Tool calls serialize cleanly; no raw XML tags appear in the output.
- A
writethat returnssuccess:truemeans the file actually exists on disk.
Screenshots/logs
- Symptom 1: the conversation fills with blocks of the closing parameter tag after tool calls.
- Symptom 2:
Test-PathreturnsFalseright after awritethat reportedsuccess:true, bytesWritten:122.
Environment
- OpenCode version:
v2.0.31(whatopencode --versionreports while running). Note:npm ls -gshowsopencode-ai@1.18.33. - OS: Windows 11 Pro Education (10.0.26100)
- Shell: PowerShell 5.1.26100.9711
- Install method: npm global (
C:\Users\Estudiante\AppData\Roaming\npm) - Node: v24.16.0
Additional context
- Restarting the session did not fix it — the corruption recurred after restart.
- Suspect the tool-call serialization path and/or the filesystem write not actually flushing to disk.
- The write reported a plausible byte count (122 lines), suggesting the content was processed but never persisted.
- Project context: a monorepo (FastAPI backend + React frontend). No antivirus observed interfering.
Activity
opencode-agent commentedon Oct 16, 2026
Thanks for the detailed report! Before we can try to reproduce this, we need a few more details:
opencode --versionreports2.0.31, but the only global npm package you listed isopencode-ai@1.18.33, which is OpenCode v1. Could you share the output ofwhere opencodeandnpm ls -g @opencode/cliin PowerShell?writestep. In v2.0.31 the built-inwritetool doesn't return{"path":…,"bytesWritten":…,"success":true}. It replies withCreated file successfully: <path>. So that result most likely came from another tool (MCP/plugin), or the model wrote it out as text during the same tag leak, in which case no write actually ran. A screenshot or export showing whether a realwritetool call appears there would settle it.You can reply here with the details or edit the issue. If you edit it, please also leave a comment saying you've updated it so we know you're done.
Possibly related issues, ordered by likelihood:
<parameter>etc.) leaking into the TUI instead of being parsed ([Bug] Raw<parameter>tool-call tags rendered literally in TUI above assistant message #45797 was closed as a duplicate of it)</tool_call>tags into the outputalesioandresv-ops commentedon Oct 16, 2026
opencode-agent commentedon Oct 16, 2026
Thanks for the quick answers, @alesioandresv-ops! That confirms the version (v2.0.31), the model (Big Pickle on the OpenCode provider) and context7 as the only MCP server.
That helps narrow things down:
write"success": context7 only provides documentation lookup and has no write tool. OpenCode 2.0.31's built-inwritetool never returns{"path":…,"bytesWritten":…,"success":true}; it replies withCreated file successfully: <path>. So no tool you have installed produces that response. Most likely the model typed that text itself as part of its reply, during the same problem where tool calls appear as plain text. If so, no write actually ran, which would explain why the file isn't there.</think>) saved as normal reply text instead of a thinking block (llm: stray closing think marker persisted as visible assistant text (opencode/big-pickle) #56104 was marked as a duplicate of it, also on 2.0.31 and Windows)To tell whether OpenCode is mishandling a real tool call or the model is writing fake ones, we need to see the session. Could you share one of these?
/exportand attach the file here (remove anything private first). Orwrite"succeeded". Please show whether it appears as a realwritetool entry (a tool block with the file path and a diff) or just as plain text in the assistant's reply.It would also help to know whether the tags still appear if you switch to a different model in the same project.
opencode-agent commentedon Oct 19, 2026
Closing this for now, since we haven't received the session export or screenshot we asked for. Without it, we can't tell whether OpenCode mishandled a real
writetool call or Big Pickle wrote the tool call and its "success" result as plain text. The{"path","bytesWritten","success"}response doesn't come from OpenCode 2.0.31'swritetool or from context7, so the second explanation is the more likely one.If it happens again, please reopen this issue or open a new one and attach either the session export (
/exportin the TUI) or a screenshot that shows whether thewriteappeared as a real tool entry. It would also help to know whether it happens with other models. Meanwhile, #54599 is the related open issue about Big Pickle putting its internal markup into the reply text.Thanks for the report, @alesioandresv-ops!