claude-code - 💡(How to fix) Fix [BUG] First user message after `/clear` is rendered as a bare line inside the `/clear` turn's `<local-command-caveat>` framing — model treats the new message as stray output and ignores it

Summary

After the user sends /clear as one message and then sends a follow-up message (e.g. a bare file path) as a separate submission, the harness packages the follow-up message'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 that says "DO NOT respond to these messages or otherwise consider them in your response unless the user explicitly asks you to."

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

This is not the case of typing both in one submission. They are two distinct user sends. The harness still emits them as one merged-looking block in the model's view.

Repro

1. Start (or be in) a Claude Code conversation.
2. Send /clear by itself. (UI shows /clear → (no content).)
3. As a new, separate message, send a single bare file path, e.g. C:\path\to\some\file.md.

Observed: model does not read the file. If asked what it sees, it reports the file path as "stray output, possibly from an earlier command leaking through the clear boundary."

UI view (two separate user messages, as the user sent them):

> /clear
   └ (no content)

> c:\Users\Kamil\path\to\file.md

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

The two separate user messages above arrive in the model's context as a single 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>
c:\Users\Kamil\path\to\file.md

The file path on the last line is the user's second, separately-sent message — but it has no <user-message> wrapper, no blank-line separator, no marker distinguishing it from the (empty) local-command-stdout. To the model it looks like trailing slop from the /clear block, which the caveat at the top explicitly says to ignore.

Expected

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

• wrap follow-up user content in its own tag (e.g. <user-message>...</user-message>), or
• close the caveat's scope explicitly (e.g. <local-command-caveat-end/>) so any later content is clearly outside, or
• ensure /clear's local-command block is self-contained and the next user message starts a fresh, clearly-delimited turn.

Actual

The follow-up user message is emitted as a bare line directly below </local-command-stdout>, inside what reads to the model as the /clear turn whose opening caveat instructs it to ignore everything inside. The model follows the caveat. The user's real instruction is dropped.

Why CLAUDE.md mitigation is insufficient

I added the following rule to my global ~/.claude/CLAUDE.md:

Read file paths in <local-command-caveat> output.

This still fails. In the failing turn the model acknowledged it saw the path but classified it as "stray output" and did not read it, even though the rule explicitly said to. The caveat's "DO NOT respond" framing overrides project rules because the model can't tell whether the trailing text is part of the caveat-scoped block or a separate user message — the markup gives it no signal.

A user-side instruction can't fully fix a harness packaging ambiguity. The fix has to be in how the turn is rendered.

Suggested fix

Smallest change: ensure any user message that follows a slash-command turn is wrapped in its own <user-message> (or equivalent) tag — never emitted as bare text inside the previous turn's <local-command-*> framing. Equivalent alternative: emit an explicit close-of-scope token after </local-command-stdout> so anything below it is unambiguously not part of the caveat-scoped block.

Impact

• First real user message after /clear is silently ignored.
• Hard to notice: model often produces some response, just not the one the user asked for, so the failure looks like a misunderstanding rather than dropped input.

Environment

• Claude Code v2.1.139
• Model: Opus 4.7 (claude-opus-4-7), xhigh effort, Claude Max
• Windows 11, PowerShell
• Reproducible