Long single-line paste collapses to a placeholder, so the slash command is never recognized and runs as a plain prompt

Version: 2.1.233, macOS. Also on disk: 2.1.229, 2.1.231, 2.1.232.

Repro

1. Compose a /compact command with a very long argument on ONE line — roughly 3000–4000 characters, no newlines.
2. Paste it into the prompt.
3. The CLI collapses it to [Pasted text #1 +N lines].
4. Press Enter.

Expected: the compaction runs.

Actual: the visible input no longer literally begins with /compact, so the slash command is not recognized. The whole thing is submitted as an ordinary prompt and the model answers it. No compaction happens, and nothing indicates the command did not fire.

Workaround

Submit it, press Escape to halt the inference — the placeholder expands into the real text — then press Enter. It works the second time because the input now begins with the literal /compact.

Why this looks like a regression

This did not happen in earlier versions. Every public description of the collapse rule is stated in lines (">4 lines", "+23 lines"), never in characters on a single line, so a long single-line paste collapsing may be new behavior.

Two recent changelog entries touch this machinery:

• 2.1.224 — "Added a cancel-and-confirm step when removing an unavailable paste changes a command's text"
• 2.1.233 — "Fixed skill/command argument substitution"

Possibly related but distinct: #85485 (pasted content reaching tool-call arguments).

Impact

The failure is silent. A user pasting a prepared /compact argument gets a normal answer instead, and may not notice the compaction never ran until much later — by which point the context they were trying to reclaim is gone.