[BUG] Title: claude --resume cannot find sessions by the ID shown in session-management tools (e.g. mcp__ccd_session_mgmt__get_session / list_sessions)

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?

*Claude Code version: 2.1.252
OS:** Windows 11

What I expected

Session-management tooling (get_session, list_sessions) returns a session ID like
local_553755dd-186d-4058-a2b5-b528b2483659. I expected that either this ID, or a clearly
documented transformation of it (e.g. stripping the local_ prefix to get a bare UUID), would
work with claude --resume <id> from a terminal, per the CLI's own --resume documentation.

What Should Happen?

1. Passing the full ID as-is:

``
claude --resume local_553755dd-186d-4058-a2b5-b528b2483659 -p "..."
`
fails with:
`
Error: --resume requires a valid session ID or session title when used with --print.
Usage: claude -p --resume <session-id|title>. Provided value
"local_553755dd-186d-4058-a2b5-b528b2483659" is not a UUID and does not match any session title.
``

1. Stripping the local_ prefix (leaving a syntactically valid UUID) and retrying from the

session's own cwd:
``
claude --resume 553755dd-186d-4058-a2b5-b528b2483659 -p "..."
`
is accepted as a valid UUID, but fails with:
`
No conversation found with session ID: 553755dd-186d-4058-a2b5-b528b2483659
``

1. This is reproducible on a session created less than two minutes earlier and confirmed to

exist (not archived, isRunning: false, correct cwd) via get_session immediately before
the --resume attempt - so it isn't a timing/propagation issue. It also reproduces on an
older, separately-created session. Same error both times.

Root cause, as far as I can tell from the outside

The session-management MCP tools (get_session/list_sessions) appear to track sessions under
a different ID namespace (local_<uuid>) than whatever local conversation store the standalone
claude CLI's --resume flag reads from. Stripping the prefix produces a real UUID, but it
still doesn't match anything the CLI can find - so these look like two disconnected ID systems,
not one ID with a cosmetic prefix.

Why this matters

This blocks a real, legitimate use case: headlessly resuming a specific existing session (to
continue its actual memory/context) from a script, using only the ID that the session-management
tooling exposes. Right now there's no way to get from "the ID my tooling shows me for this
session" to "an ID --resume will actually accept," without some undocumented, unreliable
guess-and-check.

Suggested fix

Either:
(a) have get_session/list_sessions also expose the actual ID/path claude --resume needs
(a second field, e.g. cliSessionId), so the mapping is explicit and documented, or
(b) make --resume accept the same ID the session-management tooling already returns.

Happy to provide more repro detail / logs if useful.

Error Messages/Logs

Attempt 1 (full local_ ID):
Error: --resume requires a valid session ID or session title when used with --print.
Usage: claude -p --resume <session-id|title>. Provided value
"local_553755dd-186d-4058-a2b5-b528b2483659" is not a UUID and does not match any session title.

Attempt 2 (stripped to bare UUID, run from the session's own cwd):
No conversation found with session ID: 553755dd-186d-4058-a2b5-b528b2483659

Environment:
claude --version -> 2.1.252 (Claude Code)
OS: Windows 11

Steps to Reproduce

1. Create or identify any Claude Code session and note its ID via session-management

tooling (e.g. mcp__ccd_session_mgmt__get_session), which returns an ID shaped like
local_553755dd-186d-4058-a2b5-b528b2483659.

1. From a terminal, run:

claude --resume local_553755dd-186d-4058-a2b5-b528b2483659 -p "test"
Result: "Error: ... 'local_553755dd-...' is not a UUID and does not match any session title."

1. Strip the "local_" prefix, leaving a syntactically valid UUID, and retry from the

session's own working directory:
claude --resume 553755dd-186d-4058-a2b5-b528b2483659 -p "test"
Result: "No conversation found with session ID: 553755dd-186d-4058-a2b5-b528b2483659"

1. This reproduces on a session confirmed to exist seconds earlier (not archived, correct

cwd, verified via get_session immediately before the attempt), and separately on an
older session — same error both times.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude Code version: 2.1.252

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_