Session resume silently creates new session despite valid session file and correct parameters

[lld98523]

When attempting to resume a session with a valid resume parameter and an existing session file, the SDK silently creates a new session instead of resuming the expected one. No error or warning is logged
by the SDK.

Environment

• SDK Version: 0.1.29 (also tested concept with 0.1.31)
• Python Version: 3.12
• Platform: Linux (Kubernetes)
• Storage: Shared storage (NFS) mounted at ~/.claude

Steps to Reproduce

1. Create a new session, SDK returns session_id = "61568b3d-8671-487f-a553-7647fbffff5e"
2. Save the session_id for later resume
3. Wait ~27 seconds (not a concurrency issue)
4. Resume the session with the following options:

   options = ClaudeAgentOptions(
       resume="61568b3d-8671-487f-a553-7647fbffff5e",
       fork_session=False,
       continue_conversation=True,
       # ... other options
   )

5. SDK returns a different session_id = "220a71ec-c933-4091-ac05-dc2eb8366c00"

Expected Behavior

SDK should resume the existing session and return the same session_id (61568b3d-...), or raise an error/warning if resume fails.

Actual Behavior

SDK silently creates a new session with a different session_id (220a71ec-...) without any error or warning.

Verification Done

Before reporting, we verified:

1. Session file exists and is valid:
   ~/.claude/projects/-app-project/61568b3d-8671-487f-a553-7647fbffff5e.jsonl
   Size: 21KB, valid JSONL format
2. Parameters are correctly passed:
   - resume = "61568b3d-8671-487f-a553-7647fbffff5e"
   - fork_session = False
   - continue_conversation = True
3. CWD is consistent between requests: /app/project
4. Not a concurrency issue: 27 seconds between requests, different trace IDs

Logs

First Request (08:44:57) - New Session

08:44:57.327 | SessionManager: Creating new session: app_session=e5705931...
08:44:59.882 | Captured SDK session ID: 61568b3d-8671-487f-a553-7647fbffff5e
08:44:59.883 | SDK callback on_system_init: is_resuming=False
08:44:59.886 | Saved session mapping: app_session -> sdk_session=61568b3d-...

Second Request (08:45:24) - Resume Attempt

08:45:24.553 | Redis query: is_resuming=True, sdk_session_id=61568b3d-... (correct)
08:45:24.559 | SessionManager resume session: resume=61568b3d-... (correct)
08:45:28.263 | SDK returned SystemMessage: session_id='220a71ec-...' (NEW ID!)
08:45:28.263 | SDK callback on_system_init: sdk_sid=220a71ec..., is_resuming=True, expected=61568b3d...

Impact

• Users lose conversation context unexpectedly
• No way to detect resume failure before it happens
• Silent failure makes debugging difficult

Suggested Improvement

1. Log a warning when resume fails and a new session is created
2. Or raise an exception if fork_session=False but resume fails
3. Or provide a callback/event to notify the application of resume failure

Workaround

We added detection logic in our application:
if is_resuming and expected_session_id and actual_session_id != expected_session_id:
logger.warning(f"Session resume failed: expected={expected_session_id}, actual={actual_session_id}")