Bug type

UI/state regression

Beta release blocker

No

Summary

Control UI/WebChat session names can appear to disappear even though the server-side session store still has the user-provided label.

This looks like a display/rehydration mismatch rather than true data loss: /name <label> persists label in agents/<agentId>/sessions/sessions.json, but some UI/session-list paths appear to render only derivedTitle/displayName/the raw session key after reloads, gateway restarts, or visible dashboard session-family rotations.

What happened

A dashboard session was renamed with /name <custom-label>.

Later, the same visible dashboard session appeared unnamed / UUID-like in the Control UI, making it look as if the name was lost.

Local state inspection showed the label was still present:

{
  "key": "agent:main:dashboard:<uuid>",
  "sessionId": "<current-session-id>",
  "usageFamilyKey": "agent:main:dashboard:<same-uuid>",
  "usageFamilySessionIds": [
    "<older-session-id-1>",
    "<older-session-id-2>",
    "<older-session-id-3>",
    "<current-session-id>"
  ],
  "sessionFile": "agents/main/sessions/<current-session-id>.jsonl",
  "label": "<custom-label>"
}

The active transcript for <current-session-id>.jsonl contained only the rename command and assistant acknowledgement:

session
user: /name <custom-label>
assistant: <ack>

So the user-visible name was not actually removed from sessions.json; it was either not used by the UI after state refresh, or not propagated into the field the UI currently renders.

Expected behavior

A manually named session should consistently render the user-provided label across:

• current chat header / active session display
• session picker/list rows
• page reloads / WebSocket reconnects
• gateway hot restarts
• session-family rotations where the visible dashboard key keeps the same usageFamilyKey but sessionId changes

Title fallback should consistently be something like:

derivedTitle ?? displayName ?? label ?? key

or the server should materialize displayName from label for all session-list/change payloads that UI clients consume.

Evidence from source inspection

Related code suggests the model has multiple display fields:

• src/sessions/session-label.ts parses user-editable labels.
• src/gateway/session-utils.ts builds session rows with both label and displayName; one path appears to fall back from displayName to entry.label.
• src/tui/tui-command-handlers.ts session picker title uses session.derivedTitle ?? session.displayName, while session.label is only included in searchText.
• src/acp/translator.ts already maps title as derivedTitle ?? displayName ?? label ?? key.

That inconsistency makes it plausible that some clients render raw keys even when label is still persisted.

Related issues

• Related feature request: [Feature]: /label slash command & /new <name> session naming for WebChat/Control UI #93422
• Earlier closed rename/label request: Feature: Allow renaming / labeling Control UI dashboard sessions #96187
• Possibly adjacent session-family/history issue: [Bug]: WebChat sessions_history misses prior history split into reset/archive session files for same visible dashboard conversation #92062

Privacy note

The example above is sanitized. The real local session key, label, and session IDs were only used to verify persistence locally; no private prompt content or identifying label is required to reproduce the field-mapping issue.