claude-code - 💡(How to fix) Fix Harness silently truncates Write content at literal `<` character + drops bare `<parameter>` tags (XML-parser overreach on content payloads)

Summary

Two symptoms of what appears to be the same harness bug: the content path treats unescaped < characters as XML tags and silently truncates / drops content. Symptom 2 is a clean empirical reproducer; symptom 1 is the more famous version that's been bothering MCP users for a while.

Symptom 2 (cleanest reproducer) — Write tool truncates content at first literal <

Use the Write tool to create a file whose content contains an unescaped < character inside a markdown code-span. For example, content like:

The path is `~/.claude/projects/<project>/<session-id>.jsonl`.

Observed behavior:

1. Write tool returns success.
2. On-disk content is truncated at the first <. Everything after is dropped.
3. The agent has no signal that this happened — return value is success, and a subsequent Read may serve the in-conversation cache rather than re-reading from disk.
4. cat / wc / od -c reveals the truncation.
5. If the agent rewrites the same content with < HTML-entity-escaped or with the angle bracket spelled out, the file lands correctly.

This was reproduced same-session in a multi-agent fleet on 2026-05-16. Two consecutive Write calls on the same memory file truncated at exactly the same offset (the first literal < in the content); the third attempt with < replaced by < landed all bytes.

The truncation point is deterministic: at the byte offset of the first < that is not part of a known XML envelope tag.

Symptom 1 (well-known) — bare <parameter> tag without the namespace prefix

MCP tool calls require <parameter name="..."> for parameter tags (the antml: namespace prefix). When a model emits bare <parameter name="..."> for a parameter, the harness silently drops that parameter before pydantic validation runs on the MCP server side. Error surfaces as a "required field missing" pointing at the dropped field, not at the prefix.

This is well-documented in agent-side memories ("scan your output before sending"), but the mitigation does not hold reliably — agents hit this bug repeatedly even with the memory loaded at session start. Multi-agent fleet logged 11+ occurrences across 6 agents in a single day, 2026-05-16.

Why these are likely the same bug

Both look like the harness's content path running an XML parser (or XML-aware sanitizer) on text that should be opaque to the harness:

• Bare <parameter> tag interpreted as an envelope tag the parser doesn't recognize → contents dropped.
• Literal < inside Write content interpreted as the start of a tag → everything after the < consumed by parser until end-of-input (or matching >) and dropped before the byte stream reaches the filesystem.

If correct, the fix locus is the same: tighten the harness's XML-parsing scope to only the tool-call envelope structure (the <function_calls> / <invoke> blocks themselves), and treat parameter contents and Write-content payloads as opaque bytes that pass through unchanged.

Why agent-side mitigation doesn't hold

If the harness strips the prefix or truncates content from the agent's emitted source before submitting to the MCP server or filesystem (not just from the rendered display the agent sees), then "scan your output before sending" cannot work — the source the agent inspects is already the stripped/truncated version. The agent has no way to verify what was actually transmitted.

This reframes the bug from "agent needs to remember the prefix / escape literal <" to "harness needs to stop pre-parsing content payloads it should treat as opaque."

Impact

• Every MCP-using agent hits Symptom 1 every session (multiple times per session for agents that do heavy postal / tool-call work).
• Symptom 2 is rarer but causes silent on-disk truncation — the worst class of failure (no signal to the agent, no signal to the user, surfaces only on re-read or external audit).
• Estimated per-occurrence cost: 3-5 minutes of agent attention plus correlated user-facing slowdowns. A multi-agent fleet measured 11+ Symptom-1 occurrences and 1 Symptom-2 occurrence in a single 8-hour window on 2026-05-16.

Reproducer (Symptom 2, minimal)

In a Claude Code session, ask the model to use the Write tool to create a file /tmp/repro.md with content:

The user wrote `<project>` in their note.

Then run wc -c /tmp/repro.md and cat /tmp/repro.md. Expected: full content. Observed (2026-05-16): truncation at the byte offset of <.

Related issues

• #44826 — MCP parameter parser swallows args on mismatched close tag. Different specific failure (close-tag mismatch vs. prefix-strip / <-truncation), but same parser-overreach class.
• #58086 (CLOSED) — Tool input serialization: adjacent multi-line <parameter> blocks merged into a single field. Different specific failure, same class.
• #53640 — Bash tool doesn't decode XML entities in command parameters. Same XML-aware-where-it-shouldn't-be class on a different tool surface.

These four (this issue + the three above) read as a family of bugs where the harness applies XML-aware parsing to content that should be opaque. A fix targeting the underlying parser scope would likely close several of them at once.

Suggested fix locus

• Tighten the harness XML parser to envelope-only (<function_calls>, <invoke>, plus the structural attributes on those).
• Treat the contents of <parameter> tags and the content payload of file-write tools as opaque byte streams.
• Consider rejecting tool calls with bare <parameter> (no antml: prefix) explicitly with a "did you mean <parameter>?" error instead of silently dropping — this would fail loudly instead of failing silently, which is the worst property of the current behavior.