[FEATURE] /rewind is hard-blocked over Remote Control — a type:"local" command missing from the bridge allowlist

Status Open
Reported on v2.1.224
Maintainer reply None cached
Activity 0 comments · opened Aug 7, 2026

Summary

/rewind is hard-blocked over Remote Control. Typing it in the remote UI (claude.ai/code or mobile, driving a local CLI session) returns:

/rewind isn't available over Remote Control.

This is the biggest gap in the remote-control workflow for me: I drive a desktop session from my phone, and rewind is exactly the lever you need when you're away from the keyboard and the agent takes a wrong turn. Today the only recovery is to physically walk back to the machine — which defeats the point of remote control.

Digging into the shipped bundle, this doesn't look like a missing-UI problem. /rewind is an ordinary type: "local" command that is simply absent from the bridge allowlist and declares no thinClientDispatch mode. Details below.

Not a duplicate of the existing slash-command issues

  • #28351 / #28379 are about slash commands not being routed over remote-control at all. On 2.1.224 that's fixed — commands do dispatch. /rewind is a different failure: it routes fine and is then deliberately refused by a capability gate. Fixing those does not fix this.
  • #74410 is the same shape on a different surface (Claude Desktop app, macOS, area:desktop). This is the web/mobile Remote Control surface (area:claude-code-web).

Steps to reproduce

  1. Start a session in the CLI: claude
  2. Enable remote control
  3. Open the session from claude.ai/code or the mobile app
  4. Type /rewind

Actual: /rewind isn't available over Remote Control.
Expected: the rewind checkpoint picker, or a remote-compatible equivalent.

Root cause (shipped bundle, 2.1.224)

Symbols below are the minified names from the bundle.

The gate is in resolveBridgeSlashOverride:

O("tengu_slash_command_unavailable", {
  command_name: f,
  surface: "bridge",
  reason: "unavailable_over_remote_control"
});
// -> kind: "blocked", "… isn't available over Remote Control."

It fires when neither of these passes:

function uHr(e){                       // is-supported-over-bridge
  if (e.type === "local-jsx") return false;
  if (e.type === "prompt")    return true;
  return Rfa.has(e);                   // allowlist for type "local"
}

function dHr(e){                       // find-bridge-alternative (local-jsx only)
  if (e.type !== "local-jsx") return;
  for (let t of Rfa) if (t.name === e.name && t.type === "local") return t;
  return;
}

The rewind command object:

Kkb = {
  description: "Restore the code and/or conversation to a previous point",
  name: "rewind",
  aliases: ["checkpoint", "undo"],
  argumentHint: "",
  type: "local",                 // not local-jsx
  supportsNonInteractive: false,
  load: () => …
};

// its entire implementation:
async function Vkb(e, t){
  return t.onQueryEvent?.({ type: "open_message_selector" }), { type: "skip" };
}

So /rewind is not an interactive Ink component that can't cross the bridge. It's a type: "local" command whose whole job is to emit one open_message_selector event to the host. It takes the Rfa.has(e) branch — and it isn't in Rfa:

Rfa = new Set([hYs, O4o, $4o, L4o, Qaa, bJs, mJs, xfa, OHp, …, QYo, ZYo, rua]);

For contrast, reload-skills is in that set and is the exact same shape, plus a dispatch declaration:

qkb = { type: "local", name: "reload-skills", …,
        supportsNonInteractive: true,
        thinClientDispatch: "post-text" };

/rewind declares no thinClientDispatch at all, and there is already a switch handling "post-text", "control-request", "local-then-rpc", and "twin" modes. Roughly twenty commands in the bundle set the field; rewind isn't one of them.

Proposed fix

  1. Give /rewind a thinClientDispatch mode and add it to the bridge allowlist. "control-request" looks like the intended path for a command that needs the host to open a picker — the remote surfaces appear to already have rewind UI (per #74410, Desktop-native Code sessions rewind fine), so the missing piece is the CLI side agreeing to emit open_message_selector over the bridge rather than refusing up front.
  1. If the remote client can't render the picker, a "post-text" text-mode path would still unblock the workflow: bare /rewind prints the numbered checkpoint list, /rewind 3 restores checkpoint 3. Works on any thin client with zero new UI.
  1. Either way, make the restore scope explicit over remote/rewind 3 --conversation | --code | --both, echoing the target back before applying. #64615 already flags that "restore code and conversation" as a silent default is risky locally; on a phone it's worse.

Secondary asks

  • The refusal message is a dead end. "/rewind isn't available over Remote Control." gives no reason and no alternative. Naming why, or pointing at a supported command, would help.
  • The same gate silently blocks every other command missing from Rfa. Documenting which commands are bridge-capable — or surfacing it in the remote slash menu, so unavailable commands don't autocomplete — would prevent the whole class of "typed it, got refused" confusion. Right now there's no way to know before trying.

Environment

  • Claude Code CLI 2.1.224 (build 2026-08-06T01:05:53Z, 8a2a469b68f918917492973f3b16bd1682b9f82c)
  • Linux Mint 22.3 (Ubuntu noble base)
  • Remote UI: mobile app / claude.ai/code driving a local terminal session

View original on GitHub ↗