Desktop app: remote-control session permission chip shows client default (Accept edits), never the session enforced mode (auto)

Summary

New remote-control sessions opened from the Claude desktop app display the permission chip as Accept edits while the host session is enforced auto. The chip renders a client-side default and is never reconciled with the session's actual permission mode, so the UI persistently under-states the session's autonomy.

Environment

• Desktop: Windows 11, Claude desktop app 1.26832.0 (MSIX), bundled CLI 2.1.222
• Remote host: Ubuntu 24.04, Claude Code 2.1.220 under claude remote-control (systemd unit spawns children with --permission-mode auto)

Reproduction (controlled, 2026-08-10/11)

1. Host: remote-control daemon spawns every child with --permission-mode auto (verified in child argv via /proc/<pid>/cmdline).
2. Desktop app: open a new session of that host. The chip shows "Accept edits". Do not touch it.
3. First message: ask the session to run a compound Bash command covered by no allowlist entry, e.g. echo chip-test-ok && tty.
4. The command runs immediately with no permission prompt (auto behaviour; acceptEdits would prompt for non-allowlisted Bash). The transcript stamps permissionMode: "auto" on the user-message record.

Observed on ~15 fresh sessions across one day, including the controlled run above (chip: Accept edits; enforcement: auto; command ran unprompted).

Mechanism (from the shipped client code)

1. app.asar SettingsResolver: the desktop reads the remote host's ~/.claude/settings.json (plus folder settings) to resolve defaultPermissionMode, then strips every escalating mode from remote-read settings — logged as Ignoring defaultMode ... remote-read settings cannot default to an escalating mode (strip set: bypassPermissions, auto, dontAsk). A host whose defaultMode is auto can therefore never seed the chip as auto, by construction.
2. With nothing surviving the strip, the frontend draft store (draftPermissionMode, read at task_new) falls back to acceptEdits; the remote-session dropdown offers acceptEdits|plan, with auto only behind the ccr_auto_permission_mode gate. The account is also served GrowthBook tengu_quill_harbor = "acceptEdits" — no binary on either machine reads that flag (three CLI binaries, the 39.6 MB app.asar and 8,708 V8 cache chunks byte-searched, 0 hits), so if consumed it is in the served frontend; cf. #62205.
3. The remote client pushes set_permission_mode only when the locally displayed mode changes (the hook early-returns when unchanged); the initial chip value is never fetched from nor reconciled with the host's resolved mode. The mislabel therefore persists silently, and flipping the chip per session is cosmetic and does not carry to the next session.

Impact

The UI asserts a more prompt-heavy mode (Accept edits) than the session actually runs (auto, which auto-approves classifier-safe Bash and more). An operator reading the chip concludes the session will ask before running commands when it will not — the mislabel is in the security-relevant direction. In our case the operator repeatedly "corrected" sessions that were already correct, and an infrastructure team spent a day ruling out host-side causes the client had by design.

Suggested fix

At attach/creation, display the session's actual enforcement mode (available host-side and already stamped on every transcript record), or reconcile the draft chip against the host's resolved mode; at minimum, avoid asserting a specific mode the host is not enforcing.

Related: #62205 (GrowthBook flags overriding permission defaults; currently stale with no maintainer response).