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

Status Open

Reported on v2.1.173

Maintainer reply None cached

Activity 6 comments · opened Jun 12, 2026

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

Start a Remote Control session (claude --remote-control, or enabled for all sessions).
Connect from the Claude mobile app.
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.

View original on GitHub ↗

6 Comments

DLoBoston · 2 months ago

Confirming this on v2.1.173 with a concrete real-world repro and what looks like supporting evidence for the root-cause theory here.

Setup: Claude Code runs inside tmux on an always-on headless Linux dev box; I reach it over SSH from a laptop, and drive the persisted session from Remote Control (claude.ai/code + mobile) when the laptop's away. tmux is load-bearing — without it the session dies the moment the SSH connection from the laptop closes — so Remote Control is the only practical surface for me when I'm not at the terminal.

Symptom: /clear and /compact sent from the remote surface are not intercepted — they arrive at the model as plain text and do nothing. The model confirms it still has the full prior conversation; /clear sometimes even echoes "Context cleared" while nothing is cleared (cf. #68059).

Supporting evidence for the prefix theory in this issue: every message delivered to the model through Remote Control is wrapped with a literal <system-reminder>Message sent at <timestamp> UTC.</system-reminder> prefix. The model can see the raw /clear text inside that wrapper — i.e. the command is reaching the model as content rather than being parsed locally, consistent with the server-injected prefix defeating the slash-command parser.

Impact: the documented workaround ("run /clear at the local terminal") doesn't help the away/mobile case, which is the whole reason Remote Control exists. The Remote Control docs state these text-output commands should work from mobile and web (with /mcp gated to v2.1.166+), so this reads as a regression against documented behavior.

gnus-ymd · 2 months ago

Confirming the same regression on a different account & platform, with a slightly earlier activation time — suggests a staged rollout.

Account / environment

iPhone "Claude by Anthropic" app: 1.260604.0 (App Store, released 5 days ago)
Mac Claude Code CLI: stable 2.1.153 (Homebrew Cask native build), macOS 15 arm64
Plan: Claude Max (claude.ai OAuth)

Activation timeline reconstructed from JSONL (UTC, 2026-06-12)

14:52:48 — last /compact from local TTY (no reminder) → 14:54:44 compaction succeeded (last successful compaction on this account)
15:00 – 15:34:12 — many messages, all without the reminder
15:34:12 – 15:35:57 — activation window (~1m45s); reminder prepend turned on
15:35:57 — first Message sent at reminder observed
15:53:34 — first observed failed /compact from iPhone (gap is just because no /compact was attempted between 15:35 and 15:53)

This is ~1h 11m earlier than the 16:47:41 UTC activation reported in the original post (WSL/Linux), on the same calendar day → strongly consistent with a staged server-side rollout rather than a coordinated client push.

Additional impact data point on this account

Historical baseline: hundreds of successful manual /compact events across all projects
Since ~15:35 UTC on 2026-06-12: zero successful manual compactions from iPhone (compactMetadata count = 0)
Same on a second Mac under the same account, with first reminder at 15:30:29 UTC (yet another data point for the staged-rollout hypothesis)

Affected built-in commands observed on this account include /compact, /context, /effort — i.e. it is not command-specific; the dispatcher itself is the broken layer.

mkienenb · 2 months ago

I started having the same issue yesterday with the 6/4 build date ios app - iOS app 1.260604.0.
CLI version didn't seem to matter. Same issue with 2.1.176 as well as earlier-working 2.1.168

seidnerj · 2 months ago

This is driving me crazy! please fix it!

FlintCraftTech · 2 months ago

I do at least half my work on remote control away from home, this will halve my progress developing my open source plugin for Claude.

falconbl44 · 2 months ago

Version: 2.1.173, Ubuntu 24.04, tmux RC session

Same issue. Slash commands (/clear, /compact) were working fine until June 14 — after what appears to be an auto-update to 2.1.173 they started degrading to plain text.