Remote Control regression: server-injected `<system-reminder>Message sent at …>` prefix breaks slash commands from mobile/web

Summary

As of 2026-06-12 ~16:47 UTC, messages sent from the Remote Control mobile app started arriving with a server-injected prefix:

<system-reminder>Message sent at Fri 2026-06-12 16:47:41 UTC.</system-reminder>
/clear

Because the slash-command parser only recognizes a command when the message starts with /, this prefix pushes the / off the first position, so /clear, /compact, etc. sent from mobile/web are no longer intercepted — they are delivered to the model as plain text. These commands worked fine until today.

Environment

• Claude Code CLI running 2.1.173 (2.1.174 installed, latest 2.1.175 — irrelevant, see below)
• Plan: Claude Max (claude.ai OAuth)
• Remote Control via the Claude mobile app (app up to date)
• Host: Linux / WSL2

Steps to reproduce

1. Start a Remote Control session (claude --remote-control, or enabled for all sessions).
2. Connect from the Claude mobile app.
3. Send /clear (or /compact) from the phone.

Expected: the command is intercepted and executed — exactly as it is from the local terminal, where it is recorded as <command-name>/clear</command-name>.

Actual: the command reaches the model as text — <system-reminder>Message sent at … UTC.</system-reminder>\n/clear — so nothing is cleared/compacted.

Evidence this is a fresh, server-side regression

• Across ~2,700 user messages over 40 days (2026-05-02 → 2026-06-11), the Message sent at tag appears 0 times. It first appears on 2026-06-12 at 16:47:41 UTC, and it appeared mid-session, not at session start — which points to a server-side relay change rather than a client version change.
• The string Message sent at / sent at does not exist anywhere in the CLI binaries (checked 2.1.170–2.1.174), while system-reminder and Remote Control strings are present and grep-able. So the tag is not generated by the local client — it is injected upstream.
• The same commands sent from the local terminal still work and are stored as <command-name>…</command-name>. Only the remote path (the one carrying the tag) breaks. Updating the CLI does not help (2.1.175 changelog has nothing related).

Likely root cause

The new timestamp metadata is being prepended to the raw user message text before slash-command detection runs. The parser's "starts with /" check then fails. The metadata should be attached out-of-band (or after command detection), not inlined ahead of the user text.

Impact

All slash commands are unusable from mobile/web Remote Control, despite the docs listing /clear, /compact, /context, etc. as supported from mobile/web. The only workaround is running commands from the local terminal, which defeats the purpose of Remote Control.

Suggested fix

Either strip/ignore a leading <system-reminder>…</system-reminder> block before slash-command detection on the host, or stop prepending the timestamp to the user message text on the relay.