[FEATURE] Bridged sessions should show their real title on the paired device instead of <hostname>-<slug>

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

I run Claude Code desktop on two machines under one account: a desktop and a laptop (hostname INNK), both Windows 11. Sessions started on the laptop are bridged to the desktop - their local records carry bridgeSessionIds and remoteControlAutoEligible: true.

In the desktop's session list, those laptop sessions cannot be identified by content:

• older ones show the auto-generated title exactly as it stood at creation, frozen from then on
• newer ones show a generated name such as innk-composed-book or innk-adaptive-octopus

Meanwhile the laptop's own record (%APPDATA%\Claude\claude-code-sessions\<user>\<workspace>\local_<id>.json) always holds the meaningful title. After a rename it reads "titleSource": "tool", with the previous name kept in "previousTitles". That title never reaches the desktop, including after restarting the desktop app. This was consistent across every session I checked.

So the session list on the other machine cannot be used to find a past session, which is the main thing I need it for when moving between two machines. <hostname>-<slug> tells me which machine ran it and nothing else. The useful value already exists on the originating side; it just does not travel.

Proposed Solution

A session's title should be the same on every device that lists it, and a rename should follow it there.

Any one of these would be enough:

1. Propagate title updates - including set_session_title from the ccd_session_mgmt MCP tool - to the bridged / cloud session record.
2. Seed a bridged session's display name from the session's title instead of a random slug, and keep it in sync afterwards.
3. Let the device that displays a bridged session rename it locally, and have that rename stick.

Option 2 alone would cover most of it: the auto-generated title is usually descriptive enough, and it already exists at creation time.

Alternative Solutions

I tried to work around it with hooks and could not:

• A SessionStart hook that injects context asking for a (prefix) in the title does not influence the auto-generated title.
• UserPromptSubmit cannot modify the submitted prompt text - the documented output fields are additionalContext, blockReason and systemMessage - so a marker cannot be placed into the text the title is derived from.
• Renaming through set_session_title updates the local record only, which is the behaviour this request is about.

The workaround I settled on is a Stop hook on the laptop that appends title / timestamp / cwd / session id to a file on a shared folder, so that from the desktop I can look up what a given innk-* session actually was. It works, but it is a second list to consult alongside the real one.

Typing a marker at the start of the first message also works, since the auto-generated title is derived from it - but only when I remember to, and it does nothing for the sessions that get the <hostname>-<slug> name.

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

_No response_

Additional Context

Environment: Claude Code desktop app on Windows 11 on both machines. The laptop's hostname is INNK, which is where the innk- prefix in the generated names comes from.

Same session, seen from each side:

| desktop's session list | laptop's own record |
| --- | --- |
| innk-adaptive-octopus | the title I actually set (Japanese) |
| creation-time title, frozen | current title, titleSource: tool |

Related issues

• #92644 - session title changes not propagating to the Android app. Same underlying gap, different client; this request is the desktop-to-desktop bridged case, and additionally covers the generated <hostname>-<slug> name, which that issue does not mention.
• #90433 - argues the opposite direction, that titles appearing across machines on one account is a leak. I am aware this pulls against the present request. My case is two machines I own, signed into the same account, which is why I want it - so making the behaviour opt-in (a setting, or per-device) would suit me fine, rather than always-on propagation.