[BUG] New session silently inherits the previous project's working directory with no warning — risks edits/commits in the wrong project

Summary

When a user starts a new session (Claude Desktop with integrated Claude Code), the session silently inherits the working/project directory of the previously‑used project. There is no dialog, banner, confirmation, or warning indicating which folder the new session is bound to. The user reasonably believes they are starting in a fresh/neutral context, when in fact the session is rooted in a different, pre‑existing project.

This is a data‑safety problem, not just a UX annoyance: any file‑modifying or destructive instruction the user gives ("clean up this folder", "remove the unused files", "delete the build output") can execute against the wrong project without the user ever realizing which tree is being touched.

Environment

• Claude Desktop with integrated Claude Code
• macOS 26.x (Tahoe)
• Plugins/skills/hooks enabled (not relevant to the repro, but present)

Steps to reproduce

1. Use Claude Desktop with a project, e.g. Project A at ~/projectA.
2. Click New session / New chat.
3. Begin working. Ask the assistant to edit files for a different project, Project B at ~/code/projectB, using absolute paths.

Expected

Starting a new session should make the bound folder explicit:

• Either prompt the user to pick/confirm the project folder, or
• Clearly display the folder the session is about to reuse with a warning that it is reusing the previous project — before any work begins.

A persistent, visible indicator of the active project root would also prevent the confusion entirely.

Actual

• The new session silently reuses Project A's directory as its root.
• It loads Project A's CLAUDE.md and project memory.
• It files this session's transcript under Project A's folder (~/.claude/projects/<A-slug>/<uuid>.jsonl), even though the entire conversation is about Project B.
• No warning of any kind is shown. The user only discovers the binding indirectly (in this case, because a background plugin reported activity scoped to Project A).

Impact

1. Data‑safety / potential data loss. Destructive or cleanup instructions can be executed against the unintended (inherited) project. The user has no signal that they are not in a fresh context. On its own this is the kind of silent‑wrong‑directory behavior that has already produced data‑loss reports elsewhere in this tracker.
2. Transcript cross‑filing. Conversations about Project B are permanently stored under Project A's history, polluting Project A's session list.
3. Project‑memory contamination. Auto‑memory (MEMORY.md) for Project A can accrue facts that belong to Project B.

Suggested fix

• On new‑session start, show the bound working directory prominently.
• When a new session would reuse a prior project directory, require an explicit confirmation (or default to a neutral "no project" state and let the user attach a folder).
• Add a persistent, always‑visible indicator of the active project root in the session UI.

The core ask is simple: never bind a new session to a pre‑existing project directory silently. Make the binding visible and require confirmation when it is inherited.

---

Filed by a user (GitHub @Emasoft) with the help of Claude, after hitting this in practice: a "new session" silently resumed a large unrelated project, and only a background plugin's directory‑scoped activity revealed the mis‑binding.