[BUG] Remote Control: after /login the session loses its pairing, and a re-pair is titled <hostname>-<adjective>-<noun> instead of the --name title

Status Open
Reported on v2.1.301
Maintainer reply None cached
Activity 0 comments · opened Oct 15, 2026

What's Wrong?

  1. /login drops the Remote Control pairing. After switching accounts with /login inside a session that was started with --remote-control <name>, the session is no longer on Remote Control and has to be paired again.
  2. The re-pair ignores the session's name. Running /remote-control (no argument) after the switch registers the session under an auto-generated title like <hostname>-validated-toast or <hostname>-drifting-snowflake, although the session was started with -n <name> and its transcript carries that name as its custom title.

The documented title order puts "The name you passed to --name, --remote-control, or /remote-control" first and "An auto-generated name like myhost-graceful-unicorn" last, below "The last meaningful message in existing conversation history". These sessions had both a name and a long history, yet got the last-resort title.

Control, on 2.1.301 with no account switch: a session started with -n <name> and no --remote-control, then paired with a bare /remote-control, IS listed under <name>. So the fallback appears only after an account switch.

What Should Happen?

  • Best: the Remote Control pairing survives /login (the session re-registers under the new account by itself, with the same title).
  • At minimum: a re-pair after /login uses the session's --name / /rename title, as the documented order says.

Steps to Reproduce

  1. Windows 11. Start claude -n my-session --remote-control my-session and open the Claude app on a phone: the session shows as my-session.
  2. In the session, run /login and sign in to a second account.
  3. Note the session is no longer paired. Run /remote-control with no argument.
  4. Open the session list for the second account on the phone or claude.ai/code: the session shows as <hostname>-<adjective>-<noun>, not my-session.

Is this a regression?

I don't know. The fallback was observed on 2.1.296. On 2.1.301 the no-switch control above keeps the name; the after-/login case has not been re-run on 2.1.301 (the changelog for 2.1.297 to 2.1.301 has no entry that looks like a fix).

Claude Code Version

Observed on 2.1.296. Control run on 2.1.301.

Platform / Operating System / Terminal

Claude subscription accounts; Windows 11; sessions run in a ConPTY host.

Additional Information

Impact: we run about 20 long-lived interactive sessions across two PCs and tell them apart on the phone only by name. We switch accounts with /login often (about 18 times in 3 days). Every switch drops every session's pairing, and each re-pair came back under a placeholder title: on one day nine live sessions showed only as <hostname>-<adjective>-<noun> and had to be renamed by hand.

Workaround in use: re-pair with an explicit /remote-control <name>, never a bare /remote-control. That keeps the name, but the re-pair itself is still needed after every switch.

Related: #100426 (an explicit name losing to the AI-generated title).

View original on GitHub ↗