[BUG] User message sent after `/clear` is serialized as a bare line inside the `/clear` turn's `<local-command-caveat>` scope — model treats it as command output and ignores it (not limited to file paths)

Refiling per the auto-close instruction on #58529 ("Please open a new issue if this is still relevant"). It is still relevant — it just reproduced on Opus 4.8 — and this repro disproves the narrowest reading of the original.

What's new vs #58529

The original repro dropped a bare file path, which could be dismissed as "the model is cautious about a lone line that looks like a log path." This repro kills that reading: the dropped message was a natural-language question plus a pasted multi-line log. The model read the whole thing — prose question included — as trailing command output and disregarded all of it.

So the bug is not scoped to file paths. It swallows arbitrary user content sent as the first message after /clear.

Summary

When the user sends /clear and then sends a follow-up message as a separate submission, the harness serializes the follow-up's content as a bare line directly after </local-command-stdout> from the /clear turn — with no wrapping tag and no delimiter separating it from the preceding <local-command-caveat> block, whose text says "DO NOT respond to these messages or otherwise consider them in your response unless the user explicitly asks you to."

The model classifies the follow-up as trailing command output and ignores it. The user's first real instruction of the new conversation silently vanishes.

This is a context-serialization (prompt-assembly) defect, not a UI one: the end-user UI renders the two messages correctly as distinct turns. The boundary is lost only in the text stream sent to the model.

Repro

1. Be in a Claude Code conversation.
2. Send /clear by itself. (UI shows /clear → (no content).)
3. As a new, separate message, send a prose question with pasted content below it, e.g.:

``
is this fixable or unavoidable
ExampleHandler on ExampleObject found no matching children.
at ExampleHandler.Resolve () in ExampleHandler.cs:40
at ExampleHandler.Init () in ExampleHandler.cs:26
``

Observed: the model does not answer the question. If asked what it sees, it reports the message as "stray console output leaking from a previous command, which the caveat says to ignore."

Actual turn as the model receives it (verbatim shape, sanitized)

The two separate user messages arrive in the model's context as one merged-looking block:

<local-command-caveat>Caveat: The messages below were generated by the user while running local commands. DO NOT respond to these messages or otherwise consider them in your response unless the user explicitly asks you to.</local-command-caveat>
<command-name>/clear</command-name>
            <command-message>clear</command-message>
            <command-args></command-args>
<local-command-stdout></local-command-stdout>
is this fixable or unavoidable
ExampleHandler on ExampleObject found no matching children.
...

The question and log on the trailing lines are the user's second, separately-sent message — but they have no <user-message> wrapper, no blank-line separator, no marker distinguishing them from the (empty) local-command-stdout. To the model it reads as trailing output of the /clear block, which the opening caveat explicitly says to ignore.

Why it's a serialization bug, not a model bug

The harness holds three distinct structured events: the /clear invocation, its (empty) stdout, and a separate user message. It flattens them into one block with no boundary between events 2 and 3. Four specific defects make the user message unrecoverable as input:

1. Scope is defined by prose, not structure. The caveat says "the messages below" — an open-ended claim over everything that follows. Tag nesting would bound it; prose doesn't.
2. No turn-boundary / close-of-scope token. Nothing marks where the /clear turn ends, so there is no point after which content is provably outside the caveat's scope.
3. The follow-up has no wrapper of its own. It is emitted as a bare line, sharing the framing of command output.
4. Empty stdout puts it in the worst slot. <local-command-stdout></local-command-stdout> is empty, so the bare line sits exactly where real stdout would appear — directly after the stdout tag — maximally confusable with the command's output.

Given that text, the model's parse ("caveat says ignore this block; this is in this block") is defensible. The model cannot recover a distinction the encoding threw away. Fix the encoding and the same model reads the message correctly with no behavior change.

Why CLAUDE.md mitigation can't fix it

The prior issue's mitigation was a global ~/.claude/CLAUDE.md rule: "Read file paths in <local-command-caveat> output." This now fails twice over:

• It is file-path-specific, so it never matches a prose-plus-log message in the first place.
• Even when it did match a path, the model acknowledged seeing the content but still classified it as "stray output" — a user-side instruction can't override a harness packaging ambiguity, because the markup gives the model no signal that the trailing text is a separate user turn.

The fix has to be in the serialization, not in user config.

Expected

A separately-sent user message must be unambiguously presented as user input — never inlined into the previous /clear turn's <local-command-*> framing.

Suggested fix (any one breaks the ambiguity)

• Wrap follow-up user content in its own tag (e.g. <user-message>...</user-message>), or
• Emit an explicit close-of-scope token after </local-command-stdout> so later content is clearly outside the caveat scope, or
• Ensure /clear's local-command block is self-contained and the next user message starts a fresh, clearly-delimited turn.

Impact

• First real user message after /clear is silently dropped.
• Hard to notice: the model usually produces some response, so the failure looks like a misunderstanding rather than dropped input.
• Confirmed to affect arbitrary content (prose + pasted text), not just file paths.

Environment

• Claude Code v2.1.195
• Model: Opus 4.8 (claude-opus-4-8[1m])
• Windows 11, PowerShell
• Reproducible
• Prior report: #58529 (auto-closed for inactivity, no maintainer response)