[BUG] iOS Remote Control requests disabled Auto mode on new chat, then shows Accept edits while host remains in bypass

[sleechie]

What's wrong?

Starting a new Remote Control chat from the Claude iOS app produces this banner:

Couldn't change the mode: Cannot set permission mode to auto: auto mode disabled by settings

The app shows the session as Accept edits, but the running VM session reports bypassPermissions both at startup and when queried afterward. The user did not request a permission-mode change as part of starting this new chat.

The host is enforcing its configuration correctly. The problem is that the remote client attempts to select a disabled mode during startup, then leaves the user with an error and a mode display that does not describe the running session.

This was observed on September 28, 2026, in a newly created chat, before any plan-approval flow. It is not just an inference from launch arguments: the live worker's control-protocol response confirms its effective mode.

Environment

• Host: Ubuntu 24.04.4 LTS, x86_64 Linux VM.
• Claude Code: 2.1.280.
• Remote Control server: persistent systemd service, signed in with a Claude subscription account.
• Client: Claude iOS app on iPhone; exact app/OS versions were not captured.
• Model: Opus 5.5, High effort.
• Host process runs as root with IS_SANDBOX=1.
• No host restart or configuration change occurred between observing the banner and checking the live worker.

The latest npm release when this report was prepared is 2.1.283. This report has not been reproduced on 2.1.283; the version above is the one actually observed.

Relevant configuration

User settings, with unrelated fields omitted:

{
  "permissions": {
    "defaultMode": "bypassPermissions",
    "disableAutoMode": "disable"
  }
}

Remote Control launch, with the machine name replaced:

IS_SANDBOX=1 claude remote-control --name vm-repro --capacity 64 --permission-mode bypassPermissions

Both the Remote Control server and its spawned worker have an explicit --permission-mode bypassPermissions argument.

Steps to reproduce the observed workflow

1. Configure the host with the user settings above and start the Remote Control server in bypass mode.
2. Open the host from the Claude iOS app and start a new chat.
3. Send an ordinary work request without selecting Auto or approving a plan.
4. Observe the startup banner rejecting Auto and the app's Accept edits mode display.
5. Query the running worker's effective permission mode. It is still bypassPermissions.

I have not isolated whether the startup Auto request comes from a remembered app preference, a default, or another part of Remote Control initialization. The error and effective-mode mismatch are observed; the client-side cause remains unknown.

Error messages and verified state

Selected fields from the new chat's Remote Control events, with session/request IDs omitted:

2026-09-28T15:11:52.042603Z
control_response:
  error: Cannot set permission mode to auto: auto mode disabled by settings

2026-09-28T15:11:52.168Z
local transcript user message:
  permissionMode: bypassPermissions

2026-09-28T15:11:52.289777Z
control_response:
  current_permission_mode: bypassPermissions

2026-09-28T15:13:14.645631Z
live worker queried again:
  current_permission_mode: bypassPermissions

The session's initialization event also reports permissionMode: bypassPermissions.

An iPhone screenshot captured the banner immediately after the first work request. Raw screenshots and transcripts are omitted because they contain unrelated work content.

Expected behavior

• Starting a chat should preserve the host's explicitly configured mode unless the user deliberately chooses another permitted mode.
• The remote client should honor the host's disableAutoMode capability when initializing the chat, rather than automatically sending a mode change that must fail.
• After a rejected mode change, the app should accurately indicate the effective mode. If bypass cannot be shown in the normal picker, an explicit indication such as "Permissions controlled by host" would be less misleading than Accept edits.

I understand that the current documentation explicitly says Remote Control does not report bypass to the web/mobile dropdown. That explains the display limitation, but does not explain why a new chat requests a disabled Auto mode or why the interface then suggests a different effective mode.

Impact

From the phone, this looks like the configured bypass mode failed and the session fell back to Accept edits. Auto is unavailable, bypass cannot be selected from the app, and the only way to establish what is actually running is to inspect the host. The observed session remained in bypass; this report does not claim it actually fell back to Accept edits.

Regression status

Unknown. No verified last-working iOS/CLI combination for this exact startup case.

Related reports

• Remote Control offers 'Enable auto mode' and appears to accept it on a host with disableAutoMode — app displays a mode the harness refused #80812: remote UI offers a disabled Auto mode and disagrees with host state after a manual selection. This report adds a new-chat startup case with a visible rejection and verified bypass state.
• Approving a plan from the iOS app sends setMode 'auto', discarding the session's prePlanMode; the rejection path then falls back to 'default' #93207: iOS plan approval requests Auto and can change the effective mode. This reproduction requires no plan approval, and the worker remains in bypass.
• Remote Control: mobile app shows permission prompts despite --dangerously-skip-permissions #29214: broader Remote Control bypass-permission inconsistencies.
• Permission-mode documentation.