[Bug] Remote Control slash commands silently degrade to plain text due to newline prefix

Resolved 💬 2 comments Opened Jun 15, 2026 by arslbbt Closed Jun 18, 2026

Bug Description
Title: Slash commands sent over Remote Control silently degrade to plain text (regression) Version: 2.1.159 What happens: When a message is delivered via Remote Control (claude.ai / mobile app) to a CLI session started with --remote-control, it's injected as a prompt prefixed with a \n wrapper (stored in the transcript as type: "queue-operation"). That prefix puts the reminder on line 1 and the command on line 2, so / is no longer the first character. The local slash-command parser never fires, and the command (/clear, etc.) is processed as an ordinary prompt — the model just replies (e.g. "The conversation has been cleared") while nothing actually happens. Expected: Slash commands sent over Remote Control should parse and execute the same as when typed in the local TUI. Repro: claude --remote-control <name> on a host From claude.ai / mobile, send /clear Observe: a "Brewed for Xs" turn + an assistant message claiming it cleared; context is NOT cleared. (A real /clear is silent and wipes to the startup screen.) Evidence: Transcript stores the literal content "\n/clear". The Message sent at wrapper is absent from all transcripts before ~2026-06-13 and appears only on Remote-Control-delivered messages, so this looks newly introduced (the 2.1.13x–2.1.15x Remote Control delivery changes). Not caused by user hooks. Workaround: Run slash commands in the local TUI only.

Environment Info

  • Platform: darwin
  • Terminal: vscode
  • Version: 2.1.177
  • Feedback ID: f3f6c0e1-b27b-486d-9da0-4224beb0817c

Errors

[]

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗