Session rename does not propagate to a connected Remote Control session

Summary

Renaming a session on the desktop updates the title locally but never propagates to that session's connected Remote Control view. The phone keeps showing the title the session had at the moment Remote Control was enabled, even after a subsequent publish and a full message round trip.

Reproduction

1. Start a new session in the desktop app with Remote Control enabled at startup. It auto-titles from the first prompt (New banana brief testing) and connects.
2. Rename the session from another session using the desktop app's session-management MCP tool, mcp__ccd_session_mgmt__set_session_title, to Nate: New banana brief testing.
3. Observe the new title on the desktop. get_session confirms it persisted.
4. Open the session on the desktop, which triggers a republish, then send it a message.
5. Check the phone.

Expected: the phone shows Nate: New banana brief testing.

Actual: the phone shows New banana brief testing. It receives the new message and the assistant's response in real time, so the connection is healthy — only the title is stale.

Log evidence

From ~/Library/Logs/Claude/main.log:

00:26:14  Updated session local_1d7c2b51…: { title: 'New banana brief testing', titleSource: 'auto' }
00:26:17  [remote-control] bridge_state: connected
00:27:30  handoff: publishing session_011Zmn1QpWUnc7gXNgGngLuJ
00:30:28  Updated session local_1d7c2b51…: { title: 'Nate: New banana brief testing', titleSource: 'auto' }
00:34:21  handoff: publishing session_011Zmn1QpWUnc7gXNgGngLuJ   <-- publish AFTER the rename
00:34:23  LocalSessions.sendMessage: sessionId=local_1d7c2b51…
00:34:29  [Stop hook] Query completed for session local_1d7c2b51…

The rename at 00:30:28 is followed by a genuine handoff: publishing at 00:34:21 and a message round trip, and the remote title still does not update. This suggests the remote title is captured once when Remote Control is enabled and is not part of the republish payload.

Scope / what I did not test

I reproduced this with the programmatic rename path (set_session_title). I did not test whether /rename typed inside the session propagates correctly. The documentation states renames sync bidirectionally as of 2.1.221+, so if /rename does work, the bug is specific to the programmatic path not marking the title dirty for republish.

Related observation

set_session_title returns an unconditional success string:

Renamed session <id> to "<title>". (If the user had renamed it themselves, their title is kept.)

It returns this even when the rename is silently rejected because the session was previously user-renamed (the app logs Ignoring auto-generated title for <id>: user already renamed). In a batch of 15 renames, 7 were silently refused while all 15 reported success. Callers have to re-read with get_session to learn what actually happened. A distinct return for the refused case would help.

Environment

• Claude Code desktop app 1.26832.0
• Managed CLI 2.1.222
• macOS 24.5.0
• Remote Control enabled, Team plan