Desktop app "+New" creates a session bound to the previous project instead of prompting for one

Environment

• Claude Code desktop app, Code tab
• Platform: WSL2 (Linux 6.6.87.2-microsoft-standard-WSL2) under Windows
• No integrated terminal available in the app session

Description
Starting a new chat via the "+ New" control in the sidebar does not create a session
rooted at a chosen project directory. Instead, it silently inherits the working
directory/project of whichever session was previously active, with no prompt to
select a different project. The resulting session's header shows a mismatched
project badge (a gray chip naming the old project) next to the new chat's
auto-generated title, and file cards for paths under the intended new project
do not open (they resolve against the inherited project instead).

Steps to reproduce

1. Have an active session open, rooted at project A (e.g. Project-THEA-EN.705.801).
2. Click "+ New" in the sidebar.
3. In the new chat, ask Claude to work on an unrelated project B that lives at a

different filesystem path (e.g. ~/projects/prose-voice-editor), which has
never had a desktop-app session before.

1. Observe: the new chat gets auto-titled after project B's name/topic, but the

header badge next to the title still shows project A. File cards referencing
paths under project B fail to open.

1. Right-click the session in the sidebar -> "Open in" -> new window: the new

window still shows project A's badge (confirms it's the same underlying
session/project binding, not a fresh one).

1. "More" in the sidebar only offers "Edit sidebar" -- no project picker or

project list is reachable from there to fix the binding after the fact.

Expected behavior
"+ New" should either prompt for which project/directory the new session
belongs to, or default sensibly and let the user change it before/after
starting -- not silently inherit the previous session's project with no
indication until the user notices the mismatched badge.

Workaround found
Launching Claude Code from an external terminal (cd <project dir> && claude)
correctly creates an independent, correctly-rooted session -- confirmed by
checking ~/.claude/projects/, where the CLI-launched session created its own
project directory distinct from the mis-rooted desktop-app session. This
confirms the bug is in the desktop app's session-routing UI, not in the
underlying per-directory session storage.

Impact
File cards, and presumably any other project-scoped UI affordance, silently
resolve against the wrong project -- not just a cosmetic mislabel.