SendMessage/ListAgents cross-session peer messaging broken after CCD 2.1.258 -> 2.1.260 update (Windows desktop app)

Environment

• Claude desktop app (Windows), CCD version 2.1.260, app version 1.46388.x
• Platform: win32, Windows 11 Pro

What broke
Cross-session SendMessage/ListAgents peer-messaging (used to relay messages between
multiple concurrent Claude Code sessions) stopped working after a background app
auto-update from CCD 2.1.258 to 2.1.260 (observed 2026-09-04 13:58-13:59 KST via
%LOCALAPPDATA%\Claude\logs\main.log, app version 1.44121.4 -> 1.46388.1).

Reproduction / evidence

• A long-running session was actively using SendMessage successfully while on CCD

2.1.258.

• The desktop app auto-updated in the background while that session stayed open (no

visible restart of the conversation).

• Immediately after, SendMessage calls in that same session began failing, and

ListAgents started reporting the session's own peer identity as an auto-generated
name (e.g. engine-78) with a different internal session ID, instead of its
previously-fixed name (set via /rename <name>).

• Every session created since that update (still on CCD 2.1.260) starts with

SendMessage unavailable from its very first message -- this is not limited to
sessions that were open during the update.

• Re-running /rename <name> does not restore it. The user verbally confirming session

identity in chat does not restore it either.

• This is not a platform (native-Windows-vs-WSL2/macOS/Linux) limitation: the same

session, in the same desktop app, had SendMessage working before the update.

• Not related to long-session context compaction: reproduces in sessions only minutes

old.

• Possibly related: ~/.claude.json's cached GrowthBook flag tengu_team_discovery is

false on the affected machine as of 2026-09-05 (not independently confirmed as the
cause).

Impact
Breaks any workflow relying on multiple Claude Code sessions coordinating via
SendMessage/ListAgents (e.g. a supervisor/executor/verifier multi-agent setup).

Request
Please confirm whether this is a known regression in 2.1.259/2.1.260, and if so, an ETA
for a fix or a way to roll back to 2.1.258 behavior.