`claude remote-control --permission-mode` is silently ignored (plus: held cross-session messages have no approval surface)

claude remote-control --permission-mode is silently ignored (plus: held cross-session messages have no approval surface)

Version: 2.1.240 — reproduced after a fresh update, with the host, the spawned
Remote Control sessions, and the local terminal session all on 2.1.240. Also seen on 2.1.239.
Platform: macOS 15 (Darwin 25.6.0), arm64
Surface: claude remote-control (Remote Control host + sessions driven from the mobile/web app)

Summary

Bug 1 is the substantive one: a documented flag is accepted and has no effect.

Bugs 2 and 3 are secondary. To be clear up front about bug 2: the cross-session
permission-mode gate itself appears deliberate and sensible, and I am NOT reporting it as a
defect. Messages appear to flow from a less-permissive sender to a more-permissive recipient,
but are held in the reverse direction — observed as auto -> bypassPermissions delivering
silently, while bypassPermissions -> auto and acceptEdits -> auto are held. That reads
as an intentional guard against a session with relaxed guardrails steering a stricter one.
The defect is narrower: the resulting hold renders no approval prompt anywhere the recipient's
user can reach, so the message always expires.

---

Bug 1 — claude remote-control --permission-mode <mode> has no effect

claude remote-control --help documents:

--permission-mode <mode>   Permission mode for spawned sessions
                           (acceptEdits, auto, bypassPermissions, default, dontAsk, plan)

The flag is accepted, and it is propagated onto each spawned session's argv:

10001  claude remote-control --permission-mode bypassPermissions
10002  .../2.1.240 --print --sdk-url https://api.anthropic.com/v1/code/sessions/cse_AAAAAAAAAAAAAAAAAAAAAA1 \
       --session-id cse_AAAAAAAAAAAAAAAAAAAAAA1 --input-format stream-json --output-format stream-json \
       --replay-user-messages --resume=... --permission-mode bypassPermissions

But the spawned session does not adopt the mode. Every Remote Control session ever created on
this machine records auto in its transcript, regardless of the flag:

$ for f in *.jsonl; do grep -q '"entrypoint":"sdk-cli"' "$f" && \
    echo "$f $(grep -o '"permissionMode":"[^"]*"' "$f" | tail -1)"; done

session1…  "permissionMode":"auto"
session2…  "permissionMode":"auto"
session3…  "permissionMode":"auto"
session4…  "permissionMode":"auto"
session5…  "permissionMode":"auto"
session6…  "permissionMode":"auto"
session7…  (no record; behaves as auto — see Bug 2)

Local TUI sessions (entrypoint: cli) launched with --dangerously-skip-permissions correctly
record bypassPermissions, so the mode plumbing works everywhere except the sdk-cli path.

Setting permissions.defaultMode: "bypassPermissions" in ~/.claude/settings.json does not
work around it either — a Remote Control session created after that change still came up auto.
(Verified the setting itself was live: a bare claude -p reported bypassPermissions.)

Expected: a session spawned by a host started with --permission-mode bypassPermissions
runs in bypassPermissions.
Actual: it runs in auto.

Repro

1. claude remote-control --permission-mode bypassPermissions in any project directory.
2. Connect from the mobile app / claude.ai and start a session.
3. Inspect that session's transcript under ~/.claude/projects/<dir>/<session-id>.jsonl:

grep -o '"permissionMode":"[^"]*"' <session>.jsonl

1. Observe auto, while ps shows --permission-mode bypassPermissions on the process argv.

---

Bug 2 (UX) — a held cross-session message to a Remote Control session has no approval surface

Cross-session messaging (SendMessage between local Claude Code sessions) holds a message for
user approval when sender and recipient permission-mode classes differ. The hold banner reads:

The sending session's permission mode class doesn't match this session's, so it wasn't delivered automatically.

Because of Bug 1, every Remote Control session is auto, so any message from a
bypassPermissions session is held. The approval prompt then has no surface:

• Not in the mobile/web app — the message never reaches the session, so nothing renders there.
• Not in the host terminal — that window is a status display (Connected · Capacity 1/32);

no prompt ever appears.

• The session itself is a --print subprocess with no TUI of its own.

The message sits until it expires. Sender receives:

[Cross-session delivery notice] Your message to another session was held for the recipient
user's approval … Not delivered to that session's Claude yet; its user must approve first.
…
[Cross-session delivery notice] Your message to another session was not approved before
expiry … Not delivered to that session's Claude.

Observed 4 times in a row across two different Remote Control sessions. The recipient
transcripts contain no queue-operation / queued_command records for those messages,
confirming non-delivery.

By contrast, a same-class send is delivered silently and correctly. From a bare auto-mode
claude -p, the message landed immediately, recorded as
queue-operation: enqueue → attachment: queued_command → remove, and the session replied.
So the transport is fine; only the approval path is broken.

Expected: the approval prompt is surfaced where the recipient session's user actually is
(the mobile/web app), or the sender is told immediately that this recipient cannot be prompted.
Actual: the sender is told the message "awaits approval" from a user who is never shown a
prompt; it expires silently minutes later.

Impact: the hold is unresolvable in practice for Remote Control sessions. A local TUI
session does render this prompt correctly, so the gap is specific to the sdk-cli path.

Note this is largely downstream of bug 1: if --permission-mode worked, an operator could put
the Remote Control session in a matching class and never hit the gate at all.

---

Bug 3 (minor) — recurring Session failed for stale session ids on host launch

Every claude remote-control launch in this directory reprints failures for session ids from
previous runs, which accumulate:

[11:13:47] Session failed: Process exited with error cse_AAAAAAAAAAAAAAAAAAAAAA2
[11:15:51] Session failed: Process exited with error cse_AAAAAAAAAAAAAAAAAAAAAA3
·✓· Connected · my-project · main
    Capacity: 1/32 · New sessions will be created in the current directory

The same id (cse_AAAAAAAAAAAAAAAAAAAAAA4…) failed on three separate host launches across ~20 minutes. The
host otherwise comes up healthy and new sessions work, so this appears to be a stale
per-directory session record that is retried and never cleared.

---

Notes

All evidence above is from process listings (ps), the documented --help output, and session
transcripts under ~/.claude/projects/. Nothing is inferred from behavior alone.