remote-control: client set_permission_mode=auto overrides --permission-mode bypassPermissions

Two data points from a setup that reproduces this daily, which I don't think anyone has reported yet.

Setup: macOS (headless Mac mini), device-level spawn hosts started as claude remote-control --spawn=same-dir --permission-mode bypassPermissions (one per project dir, in tmux). Claude Code 2.1.234/2.1.235. Project .claude/settings.local.json also sets permissions.defaultMode: "bypassPermissions". ps confirms every spawned child carries --permission-mode bypassPermissions in its own argv.

1. The override is create-time only, and client-specific. Same host, same argv:

• Sessions created from claude.ai/code (web) come up bypassPermissions. The web picker doesn't offer bypass, but the session adopts the host/settings-resolved mode once it starts.
• Sessions created from the Android app come up auto: every user turn in the transcript JSONL is stamped "permissionMode":"auto". The app appears to send its own default (or whatever the picker had) with the create request.
• A web-created bypass session later driven from the Android app stays bypassPermissions. Clients don't stomp existing sessions; only the mobile create flow imposes a mode.

So the bug looks confined to the mobile app's session-create payload, not per-turn mode handling. That's consistent with #88840 (argv verified, transcript says auto) and with the client-side mode-selection behavior described in #85647.

2. Workaround that holds up: adding permissions.disableAutoMode: "disable" to the project's .claude/settings.local.json fixes it, with no host restart (spawned children read settings at start). With auto unavailable, phone-created sessions fall through to the host's --permission-mode flag and land in bypassPermissions -- verified in three fresh phone-created sessions, all turns stamped bypassPermissions. From the app: choosing auto at create errors and then proceeds; choosing manual gets upgraded to bypass at session start. This matches #80812, where a disableAutoMode host refused the app's auto request.

Docs note: https://code.claude.com/docs/en/permission-modes currently says the app can't select Auto for Remote Control sessions and that --permission-mode outranks settings files; the Android create flow contradicts both.

Same on v2.1.270, Linux. Host runs claude remote-control --permission-mode bypassPermissions as a systemd unit and ~/.claude/settings.json has defaultMode: bypassPermissions. A session opened from claude.ai/code still starts in whatever the dropdown sends (auto here), and the dropdown offers no bypass entry, so the host flag has no effect at all. The docs confirm the dropdown never shows bypass for Remote Control. Either honour the host mode as the session mode or reject the flag at startup; silently ignoring it is the worst of the options. Related: #79990.

I'm hitting this with Claude Code 2.1.287 on a Linux OptiPlex, accessed through Remote Control from Claude Desktop on Windows.

The OptiPlex is configured for bypass permissions in both places:

• The running systemd user service starts claude remote-control with --permission-mode bypassPermissions.
• ~/.claude/settings.json sets permissions.defaultMode to "bypassPermissions".

All four running Claude session processes also have --permission-mode bypassPermissions in their command-line arguments.

Despite that, the remote interface shows Auto, offers only Auto / Manual / Accept edits / Plan, and commands are still being blocked. Enabling Allow bypass permissions mode in Windows Desktop exposes Bypass permissions for local Windows chats, but it does not expose that option for the OptiPlex Remote Control sessions.

Expected: Remote Control should honor the host's configured Bypass permissions mode and show the effective mode clearly. There should also be a supported way to select it remotely when the host has explicitly enabled it. Configuring bypass on the host should not leave the remote workflow stuck in Auto with no Bypass option.