Auto-assign spawned/child sessions to their parent's sidebar group

+1 — and I'd argue the general case is stronger than the child-session framing in the title.

I run ~320 active sessions with a weekly audit that sorts them into 19 topic buckets. Because there's no group field on the MCP surface, the audit can only encode the bucket as a title prefix (‹Deploy›, ‹CMS›, …) so I can sort and hand-drag sessions into the real sidebar groups. This week it flagged 147 sessions needing placement. The agent can retitle all 147 in one batch via set_session_title — and then I still do 147 manual drags, because the one step it can't do is the actual grouping.

Two concrete asks, matching (b) above:

• expose the group on session metadata from list_sessions / get_session (today: sessionId, title, cwd, branch, prNumber, prState, isArchived, isRunning, lastActivityAt — no group)
• add a set_session_group alongside the existing set_session_title

Precedent worth noting: #75733 asked for this same shape — "expose rename to the agent" — and set_session_title shipped. Group assignment is the same request one field over. Title-prefixing is only a workaround because grouping isn't reachable.

The read half of this has since shipped — list_sessions / get_session now return group: {id, name}. Only the setter is still missing, which narrows the ask from a feature set to a single tool.

Two findings that may help scope it.

The capability already exists internally. The desktop app exposes an IPC channel …_$_LocalSessions_$_setCustomGroups, handled main-side by customGroups.replace(...), and it takes effect live with no restart — it's what the renderer calls when you drag a row into a group. So this reads as exposing existing plumbing rather than building new behavior.

Writing the config file is not a viable workaround. Group assignments live in claude_desktop_config.json under preferences.epitaxyPrefs["dframe-group-scopes"] (groups / assignments / order). The config-store class does have a _watch() that emits change on external writes, but it is gated behind a watch constructor option, and watch: never appears in the bundle — so it is never enabled. Verified both directions: written while the app is running, get_session still reports group: null; the same write survives a full quit and takes effect on next launch.

The concrete case this blocks. I hand sessions off before they fill up: the dying session writes a handoff file and creates a one-time scheduled task that opens the successor. That successor carries scheduledTaskId, so it lands under Routines only — not a normal chat, not groupable (the #78229 shape). The work itself continues fine and the successor picks up the handoff automatically, but the session is unreachable from the sidebar until the next full app restart, when an external script can finally rewrite the config. A set_session_group would remove the restart from that loop entirely.

Environment: Claude Desktop 1.40609.0 on Windows 11, Claude Code 2.1.247.

An update on the premise, as of the current desktop app: the session tools now expose a group field (list_sessions / get_session), and the sidebar tools (create_group, move_sessions) let an agent file sessions into groups. So option (b) is effectively possible today. A child can call get_session("self"), follow parentSessionId up to its root, and move_sessions(["self"], <root's group>). I'm doing that with a CLAUDE.md rule.

It's still a workaround, though. It only works if every child session follows the rule. Also, archived sessions can't be filed into a group, and a group is flat, so it keeps a family together without showing who started whom. In my case the family was four levels deep, with archived sessions partway down the chain.

I've opened #95195 for the other half of this: a sidebar tree view built from parentSessionId. Automatic group inheritance here plus a tree view there would cover both needs.