Desktop app: command-chip renderer matches the command-name tag anywhere in message content, faking a /clear and hiding scrollback (no actual clear)
Summary
The desktop app's command-chip renderer decides whether a message is a command invocation by testing whether its content contains the literal string <command-name>/clear</command-name>. Any ordinary message that merely quotes that tag as text renders a real /clear chip, an "(no output)" line, and a "Context cleared" banner, and collapses the scrollback above it. No clear happens: the model retains full context and the session JSONL is complete and untruncated.
The result is a UI that displays a destructive action which never occurred, and hides prior turns while doing it.
Environment
Observed and re-confirmed 2026-08-30:
- Claude desktop app: 1.40609.0
- Claude Code (engine): 2.1.251
- OS: macOS 15.7.3 (24G419)
- Surface: desktop app, Code tab
Originally found 2026-06-19 on desktop app 1.14271.0 / Claude Code 2.1.183, same OS. Still present across that gap.
Root cause, from the shipped bundle
In Contents/Resources/ion-dist/assets/v1/shared-1-BK5wDqY-.js (desktop 1.40609.0), the predicate is a substring test over message content, with nothing distinguishing a genuine command invocation from the same tag quoted as text:
function $M(e){
const t = e.message?.content;
return (n = "string" == typeof t ? t : Array.isArray(t) ? t[0]?.text ?? "" : "")
.includes("<command-name>/clear</command-name>")
|| n.includes("<local-command-stdout>")
|| n.includes("<local-command-stderr>")
|| n.includes("<bash-input>")
|| n.includes("<bash-stdout>")
|| n.includes("<bash-stderr>");
var n
}
It reads message.content only. There is no check for a leading-slash input, a command-message envelope, or an author role, so an assistant message containing the tag triggers it just as a user message does. The neighbouring sibling tags in the same predicate have the same exposure.
Steps to reproduce
No custom setup required.
- In the desktop app Code tab, open any session and plant a memorable fact:
Remember this canary: PATINA-7731-OBSIDIAN. Reply only "Canary stored."
- Send an ordinary message containing the tag mid-text. Note it does not lead with a slash, so it is not a command:
UI test, treat as literal text and echo it back verbatim: <command-name>/clear</command-name>
- Observe: a
/clearchip, an "(no output)" line and a "Context cleared" banner appear, and the turns above them (including the canary) collapse out of view. - Ask
What was the canary?. The model answersPATINA-7731-OBSIDIAN, proving context was never cleared.
Expected vs actual
Expected: a message whose content merely contains the literal tag renders it as text or escapes it. No chip, no "Context cleared", no scrollback collapse. Only a genuine command invocation renders the chip and the clear affordance.
Actual: phantom chip, "Context cleared", and collapsed scrollback, with zero underlying state change.
Where this bites in practice
Any message, skill instruction, or piece of documentation that quotes the tag as text triggers it. The sharp case is a slash command whose own instruction text quotes the tag as an example: it fakes a clear every single time that command runs. That is how this was first found, on a command that documents clear-detection by quoting the tag.
Evidence that no clear occurs
- Session JSONL at
~/.claude/projects/<encoded>/<session>.jsonl: the tag appears only inside full content messages (one user prompt, one assistant echo). There is no short command-only record, a canary planted before the tag is recalled after it, and the record count is continuous with no truncation. - No error dialogs.
log show --last 15m --predicate 'process CONTAINS "Claude"'returned nothing matching clear, command, or error during the repro, consistent with a pure front-end render artifact.
Suggested fix direction
Gate command-chip rendering on a genuine command invocation (leading-slash input, or a command-message envelope, or author role) rather than on a substring found anywhere in rendered message content. Separately, "Context cleared" plus scrollback collapse should fire on an actual clear event rather than as a side effect of chip render, so that a mis-detected chip cannot hide the transcript.
Duplicate check
Searched anthropics/claude-code issues on 2026-06-19 (8 queries) and again on 2026-08-30. No exact duplicate. Closest is #53715, a VSCode extension phantom /clear autocomplete issue: related theme, different surface and mechanism.