set_session_title with an unknown session_id silently renames the CURRENT session instead of erroring

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Desktop app, macOS (Darwin 24.6.0), heavy multi-session workflow (20+ concurrent sessions in one repo coordinating via cross-session messaging).

The session-management MCP tool set_session_title, when given a session_id it cannot resolve, silently renames the CURRENT session and reports success, instead of erroring. The calling session ends up wearing a title claiming to be a different session, actively misrouting any mail addressed by title.

Why unresolvable ids occur constantly in real multi-session use (context, measured): session identity fragments across namespaces. After resume/fork, the head lines of the new transcript retain the prior session's sessionId, so peers and docs keep circulating ancestor ids. Measured in one project: 139 transcript files under ~/.claude/projects are really 114 sessions; union-finding co-occurring ids yields 15 lineage chains dragging 24 dead alias ids (one chain has 7). Additionally, for some sessions the local_<uuid> id from list_sessions matches no transcript filename at all, while list_events can still read them, and get_session exposes no transcript path or alias list, so callers cannot pre-validate an id themselves.

In that environment, a tool that falls back to self on an unresolvable id is the most dangerous failure shape: an action meant for session A executes on session B and reports success.

Related open issues that look like adjacent symptoms of the same identity-fragmentation class, none covering this exact fallback: #80906 (titles bleed across forked/resumed sessions), #86531 (/rename renames other concurrent sessions), #84924 (set_session_title success but no persist for idle sessions), #88777 (cross-session SendMessage reports success for undelivered messages).

Happy to provide the measurement script (filename vs head/tail sessionId union-find over ~/.claude/projects).

What Should Happen?

The call fails loudly with an error identifying the unknown session id. No session-management tool should fall back to targeting the current session when given an id it cannot resolve: error, never fall back, across the whole session-management surface (rename, archive, message-send). Ideally get_session/list_sessions would also expose enough for callers to pre-validate ids (transcript path and/or known alias ids from resume/fork lineage); I will file that separately as a feature request per the single-bug rule.

Error Messages/Logs

No error produced; that is the bug. Tool result was:

    Renamed this session to "x-mCCMH original (superseded, mail routes to 6bff874f) | CF-20260811-1753" (was "mCCMH | mentor (og CCMH) | CF-20260820-1900")

The `(was ...)` title shows it targeted the CURRENT session; the `session_id` passed belonged to a different (older) session.

Steps to Reproduce

1. In a session with the session-management MCP tools available, call set_session_title with title set to anything and session_id set to a valid-format id NOT returned by list_sessions or search_session_transcripts (e.g. a uuid harvested from transcript text, given as local_<uuid> like listed ids are).
2. Observe the tool renames the CURRENT session and reports success, rather than erroring on the unknown id.
3. (Recovery in the wild: call it again with session_id: "self" to restore the real title.)

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

1.34493.1 (Claude desktop app, macOS; bug hit via the app's session-management MCP tools)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

_No response_