Desktop app silently resumes dormant session from wrong directory

Description

The Claude Code desktop app (macOS) silently resumed a 5-day-old dormant session instead of the most recent active session, with no indication to the user.

Steps to reproduce

1. Have an active session running from ~/Projects (session A, 33MB, heavily used all day)
2. Have a dormant session from ~/ (session B, last activity 5 days ago) that was never explicitly closed
3. Close the app or let it sleep
4. Reopen the app — session B is presented on screen instead of session A
5. User types into what they see, not realising they are in the wrong session

Expected behaviour

The app should resume the most recently active session, or at minimum present a clear indication of which session/directory is active.

Actual behaviour

The app resumed session B (5 days dormant, started from ~/) instead of session A (active today, started from ~/Projects). There was no visual cue that the session had changed. The user only discovered the problem when context from earlier in the day was missing.

Evidence from JSONL

The JSONL transcript for the dormant session shows zero lines between the last activity on 7 March (09:55) and the user's new input on 12 March (23:08). The 5-day gap confirms the session was completely idle — the app kept it alive and then silently presented it.

Impact

• User loses access to their active session context
• Work typed into the wrong session cannot easily be recovered to the right one
• Session started from ~/ does not load project-level .claude/ configs, MCP servers, or CLAUDE.md — tools and instructions silently missing
• No warning or prompt that the resumed session is from a different directory

Environment

• macOS (Darwin 25.3.0)
• Claude Code desktop app (not terminal)
• Claude Opus 4.6

Related issues

Possibly related to session management issues reported in #27463, #29220, #31787 — all involve unexpected session resumption behaviour.