[BUG] VS Code extension: a plain message starting with an absolute path is misdetected as a slash command, losing the collapse control and hiding the response

Summary

In the VS Code extension's native chat panel, any user message whose text begins with / is flagged as a slash command — including a plain message that merely starts with an absolute file path. Command-flagged messages are rendered by a separate branch that returns early, before the collapsible message component, so they get no "Show more"/"Show less" control and no height clamp. A long pasted prompt beginning with a path therefore renders fully expanded at natural height and takes over the panel, hiding Claude's response and tool activity while the turn runs.

This is distinct from the existing reports (#88512, #72590, #92941, #69771), which all concern genuine slash commands / skills with long arguments. Here there is no slash command at all — it is ordinary prose that happens to open with /Users/.... That makes the trigger far more common than the current issues suggest (any macOS/Linux user pasting an absolute path first), and it points at a much narrower fix: tighten the detection rather than change the command rendering.

Version

• Extension: anthropic.claude-code-2.1.263-darwin-arm64
• CLI: 2.1.246
• macOS (Darwin 25.6.0), Apple Silicon

Steps to reproduce

1. Open the Claude Code panel in VS Code (native panel, not the integrated terminal).
2. Send a message whose first character is / because it opens with an absolute path, followed by several paragraphs of ordinary text. For example:

/Users/me/notes/handoff-2026-09-09.md
Please pick this up. <~3000 more characters of normal prose across several paragraphs>

1. Observe the sent message.

Expected: the message renders like any other long user message — clamped, with a "Show more"/"Show less" control.

Actual: it renders fully expanded in a monospace font with no collapse control of any kind, occupying the whole panel. The composer shows "Queue another message…" while the turn runs, but the response and tool calls underneath are not visible.

Reproduces deterministically, including in a brand-new conversation with the same text. Prefixing the message with any character before the / (e.g. Continue: /Users/...) renders normally with the collapse control present — that is a reliable workaround and a clean A/B for the cause.

Root cause (from the shipped bundle)

Detection — webview/index.js, message parsing:

let Y = qK0(J) || J, X = Y.startsWith("/");
return { type: "text", text: Y, isSlashCommand: X }

isSlashCommand is set purely from startsWith("/"), with no check that the remainder resolves to a known command, no rejection of strings containing / path separators or a file extension, and no length or newline check.

Render — same file, user-message renderer:

case "text":
  if (b.isSlashCommand)
    return D("div", { className: `${X5.userMessage} ${X5.slashCommandMessage}`, children: b.text }, L);
  break;
}
// normal path below: userMessageContainer + attachments + the collapsible component

The command branch returns early, bypassing userMessageContainer and the component that supplies the expand/collapse affordance. The class it applies adds only styling, no clamp:

.slashCommandMessage_07S1Yg { font-family: var(--app-monospace-font-family); font-size: .9em }

The monospace rendering is a useful visual tell that a message has been misclassified — in the affected conversation the prompt is monospace while normal messages are not.

Corroboration

Across ~90 recent local conversations, exactly one has a first user message beginning with / (a 4,055-character prompt opening with an absolute path) — and that is the one exhibiting the frozen, uncollapsible block. Every other conversation containing absolute paths has them later in the message and none show the behaviour.

Suggested fix

Narrow the isSlashCommand test, e.g. require all of: no whitespace or newline before the end of the first token; the first token matches a known/registered command name; and the text does not look like a path (no / after the first character, no file extension). Falling back to the normal collapsible renderer whenever the command is unrecognised would also make this failure mode non-destructive.

Independently, it seems worth giving the command branch the same clamp/collapse wrapper as ordinary messages, so that a genuinely long command can never hide the response either — which would also address #88512 and #72590.

Related

#88512, #72590, #92941, #36146, #72707 — same "no collapse control, response hidden" outcome, different trigger. #69771 and #63804 are closed but describe the same failure mode.