Remote Control offers 'Enable auto mode' and appears to accept it on a host with disableAutoMode — app displays a mode the harness refused

Environment

• Claude Code CLI 2.1.218, VS Code extension host session, Windows 11 Pro (build 26200)
• Session driven via Remote Control from the claude.ai Android app (current as of 2026-07-24)
• ~/.claude/settings.json (user scope, abridged — allow/ask lists omitted):

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "disableBypassPermissionsMode": "disable",
    "disableAutoMode": "disable"
  }
}

Steps to reproduce

1. Run a local session under the settings above. Locally (CLI / VS Code extension), Auto and Bypass are correctly absent from the mode picker — the kill switches work.
2. Drive that same session from the claude.ai app via Remote Control.
3. Open the mode selector in the app — Auto is still offered. Tapping it shows the "Enable auto mode?" dialog ("Claude will decide which actions are safe to run without asking. …").
4. Tap Enable auto mode.

Expected

Either of:

• Remote Control honours disableAutoMode and does not offer the Auto option for a session hosted on a machine that disables it (matching the local pickers), or
• the toggle fails visibly — e.g. "Auto mode is disabled by this machine's settings" — instead of appearing to succeed.

Actual

The toggle appears to succeed (no error), but the local harness refuses the switch:

• the session transcript records "permissionMode": "acceptEdits" on user messages sent after the toggle;
• permission ask rules (e.g. Read(~/.ssh/**)) still fire and prompt on the remote device, waiting for a human tap.

So enforcement is correct (good!), but UI state and enforced state disagree: the app displays a mode the host machine refused. To a user this reads as either a working bypass (alarming) or a silently broken toggle (confusing). For organisations that standardise on disableAutoMode as a kill switch, the remote surface looks non-compliant even though it is compliant — and on a machine without the kill switch, nothing in the UI hints that the org intended Auto to be unavailable.

Notes

• The permission-modes documentation states Auto/Bypass can't be selected from the app; the dialog above suggests the current app build does offer Auto for a locally-hosted session.
• Enforcement was verified by direct test on the host, owner-attended: transcript permissionMode unchanged across the toggle, plus an ask-walled read still prompting to the phone and requiring approval before the tool result returned.