Interactive `claude` launched in a subfolder is filed under a parent dir — shared daemon / bg-spare pool appears anchored to the wrong cwd

Summary

When claude is launched interactively from a project subdirectory, the session is recorded and stored under a different (parent/umbrella) directory than where it was launched. The launch directory is effectively ignored. Headless claude -p from the same folder roots correctly, so the bug is specific to the interactive (daemon-backed) path.

Net effect: every interactive chat started in any subfolder pools into one umbrella project, silently. Project isolation is broken.

Environment

• Claude Code v2.1.177, Linux (aarch64), shell zsh. Reproduces with and without tmux.

Steps to reproduce

1. cd ~/Apps/spec-kit (a git repo that is a subfolder of ~/Apps).
2. Run claude (interactive).
3. The conversation is stored under ~/.claude/projects/<encoded ~/Apps> with recorded cwd = ~/Apps — not ~/Apps/spec-kit.
4. Contrast: claude -p "..." from the same directory is correctly stored under <encoded ~/Apps/spec-kit> with cwd = ~/Apps/spec-kit.

Expected

Interactive claude should root the session at its launch directory (the cwd of the front-end), identical to headless -p. Launching in ~/Apps/spec-kit should create/append a ~/Apps/spec-kit project.

Actual

The session's recorded cwd and project bucket is the parent umbrella dir (~/Apps), regardless of the actual launch directory.

Evidence (live /proc/<pid>/cwd + cmdline)

• The interactive front-end processes are correctly in the subfolder: multiple claude processes with cwd = ~/Apps/spec-kit.
• There is a single shared claude daemon run process, plus a pool of pre-spawned --bg-spare worker processes. The majority of those spares are anchored to ~/Apps (the umbrella), with only a couple at the actual subfolder.
• Filesystem ground truth: every interactive session created from the subfolder was filed under the ~/Apps project with cwd = ~/Apps. The only session correctly filed under the subfolder project was a headless -p run.

This points to the daemon binding sessions to a pre-warmed worker's anchored cwd rather than the front-end's actual launch cwd.

Impact

• Conversations started in different project subfolders all collapse into one parent project — confusing and, for users who organize work per-subfolder, effectively makes per-project sessions impossible via the normal interactive flow. (User report: "I can only have 1 instance" / "everything just falls into ~/Apps.")

Requests

1. Root interactive sessions at the front-end's launch cwd (match -p behavior); the daemon should not bind a session to a spare worker whose cwd differs from the launch directory.
2. Provide a documented setting/env to disable the shared background daemon / spare-worker pool, so each claude is an independent process rooted where it is launched.

Related

#68373 — covers the (separate) issue of how this same bug report was mishandled in-session. This issue is the underlying product defect.