/remote-control fails silently on FIRST in-session invocation, succeeds on retry (v2.1.212, Linux)

Summary

In an interactive session, the first /remote-control invocation fails completely silently — the command executes, prints nothing (no success, no error), and the session does not register on claude.ai/code. Invoking /remote-control a second time succeeds immediately. Reproducible on a healthy connection (other sessions register fine at the same moment).

Environment

• Claude Code v2.1.212, native installer
• Ubuntu (kernel 6.8.0), sessions running inside tmux panes
• Claude Max (20x) account, OAuth login (claudeAiOauth, valid tokens verified)

Steps to reproduce

1. Start a fresh interactive session: claude (no --remote-control flag).
2. Type /remote-control (or /rc) and submit.
3. Observe: no output whatsoever; ~/.claude/sessions/<pid>.json has no bridgeSessionId; the session does not appear on claude.ai/code.
4. Type /remote-control again.
5. Observe: registration succeeds (bridgeSessionId present, session visible in the web/mobile app).

Reproduced twice in controlled probes (fresh sessions, scripted keystrokes, state read from ~/.claude/sessions/<pid>.json), and matches the experience in 3 real sessions today. A /rename before the first attempt makes no difference (tested both ways — the first attempt fails with or without it, the second succeeds with or without it).

Related observation (launch-flag path, same silent-failure UX)

Earlier the same day, during what appears to have been a ~2h server-side auth incident, sessions launched with --remote-control <name> also failed to register, again with zero user-visible output. The only trace was in --debug-file:

[code-session] Session create failed 401: Authentication failed
[remote-bridge] createCodeSession failed (attempt 1/3), retrying in 405ms
[remote-bridge] createCodeSession failed (attempt 2/3), retrying in 842ms
[bridge:repl] handleStateChange state=failed detail="Session creation failed — see debug log"
[bridge:repl] Init returned null (precondition or session creation failed); consecutive failures: 1

The sessions kept working normally otherwise, so the missing registration was discovered only when the phone app showed nothing. Possibly related: #78364 (init latch after 3 transient failures), #77282 (flag silently ignored at startup on Linux) — but the first-/rc-fails/second-succeeds pattern above reproduces on a healthy server, so it looks like a distinct init-ordering issue rather than the transient-failure latch.

Expected

• /remote-control prints an explicit success or error message — never nothing.
• A failed RC registration (flag or slash command) surfaces a user-visible warning in the session, not only in --debug-file.

Workaround

Type /remote-control twice. For launch-flag sessions, verify registration via bridgeSessionId in ~/.claude/sessions/<pid>.json rather than trusting the flag.