[BUG] /remote-control is unregistered (reports "unknown command") instead of naming the reason it is unavailable

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Remote Control has several independent availability gates. Two of them produce a clear, actionable message. Two others unregister the slash command entirely, so it reports unknown command — indistinguishable from the feature not existing, or from me misremembering the name.

A human-readable reason string already exists in the code for every one of these cases. It just isn't reached when the command is hidden.

Four ways Remote Control can be unavailable, two different behaviors:

| Blocker | What the user sees |
|---|---|
| Server-side org policy | "Remote Control is disabled by your organization's policy. Contact your organization admin for access." — clear |
| Managed setting disableRemoteControl | Message naming the setting explicitly — clear |
| Custom ANTHROPIC_BASE_URL | unknown command |
| Feature-flag rollout (not_in_rollout) | unknown command |

What Should Happen?

Keep the command registered whenever the feature exists in the build, and have it print the reason instead of being hidden. For the custom-endpoint case, something like:

Remote Control requires a direct connection to api.anthropic.com and is unavailable because ANTHROPIC_BASE_URL points at a custom endpoint.

The reason-computing function is already there and already covers every case — custom endpoint, cloud session, managed setting, subscription requirement, not-in-rollout. Hiding the command is what discards it.

Two smaller follow-ons:

• Have /status or /doctor state Remote Control availability and the reason, next to where /status already reports the custom endpoint.
• Close the asymmetry with the launch flag, which does surface a reason where the slash command doesn't (see #72749, which shows claude remote-control printing "Remote Control is only available when using Claude via api.anthropic.com" for the same gate that leaves the slash command unknown).

Error Messages/Logs

> /remote-control
unknown command

Steps to Reproduce

1. Sign in with a claude.ai account (mine is Enterprise).
2. Set ANTHROPIC_BASE_URL to any host other than api.anthropic.com — e.g. a corporate API gateway. Setting it in ~/.claude/settings.json under env is the common enterprise arrangement.
3. Run /remote-control.

Actual: unknown command.

Claude Model

_No response_

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.231 (Claude Code), macOS arm64, homebrew cask

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Why this is worse than it looks

claude --help lists --remote-control [name] and --remote-control-session-name-prefix <prefix> unconditionally — the flags are documented even when the slash command reports itself unknown. So the CLI's own help advertises a feature that the CLI then denies having. That is the whole confusion in one line.

The /teleport what's-new entry also says "Run /remote-control to take this session with you"; I haven't checked whether that surface is gated the same way as the command.

No diagnostic path

/status does report that ANTHROPIC_BASE_URL points at a custom endpoint, but never connects that fact to Remote Control being unavailable, and /doctor doesn't mention Remote Control at all. Working out why the command didn't exist required dumping strings out of the binary — there was no user-facing way to find out.

Orientation (minified symbols, build 2.1.231)

Offered only as a pointer into the bundle:

• _ke(e) — host allowlist, a single inline literal ["api.anthropic.com"], appearing exactly once in the binary
• hjt() — returns true if ANTHROPIC_BASE_URL is unset or passes _ke
• ort() → Q5t() → OO() — availability chain; OO() also depends on the tengu_ccr_bridge flag, default false
• the command object: { name: "remote-control", aliases: ["rc"], isEnabled: fbS, isHidden: !OO() } — this is where the command disappears
• Wxo() — already returns the human-readable reason for each case; unreachable when hidden
• Smn() — returns not_signed_in | api_key_auth | no_profile_scope | not_in_rollout

Related, but not duplicates

• #72749 — feature request to allow Remote Control behind a transparent proxy. This report is not about changing the gate, only about the gate being unexplained. It does show the launch-flag path printing a reason for the same condition.
• #81546 — docs clarification on why the eligibility restrictions exist.