[BUG] Interactive sessions overwrite CLAUDE_CODE_TASK_LIST_ID with the project basename (regression 2.1.212 -> 2.1.214, still in 2.1.215)

Summary

Since 2.1.214, interactive sessions ignore the CLAUDE_CODE_TASK_LIST_ID a user launches with. At startup the CLI rewrites process.env.CLAUDE_CODE_TASK_LIST_ID to the bare project directory basename and uses that as the task list. Every concurrent tab in the same repo therefore shares one task list. Headless (claude -p) still honors the variable. Worked correctly through 2.1.212.

Environment

• Claude Code 2.1.215 (native build, macOS arm64, Darwin 25.5.0)
• Launched from a zsh wrapper: CLAUDE_CODE_TASK_LIST_ID="$(basename "$PWD")-<8 hex>" command claude

Evidence

1. The variable reaches the process. ps eww <claude pid> (exec-time env on macOS) shows:

CLAUDE_CODE_TASK_LIST_ID=danda-new-engine-9247cc47

1. Inside the same session, every Bash tool child sees the value rewritten:

CLAUDE_CODE_TASK_LIST_ID=danda-new-engine
No shell init file, VS Code setting, or parent process sets that bare value (all checked); the mutation happens inside the CLI process after startup.

1. The session's TaskCreate/TaskList operate on ~/.claude/tasks/danda-new-engine/. A directory for the launched id (danda-new-engine-9247cc47) is never created. Two tabs in the same repo see and edit each other's tasks live.
2. The value is a replacement, not a sanitizer: suffixes of the form -<pid>-<epoch> and -<8 hex> are both discarded wholesale; the result is always exactly the cwd basename.
3. Headless honors the var (verified 2026-07-18 on 2.1.214: claude -p with probe ids probe-unique-777 and probe-suffix-12345-1784313000 each created their exact directory).
4. The bundled resolver checks the env var first (if (env.CLAUDE_CODE_TASK_LIST_ID) return it; ... teamName; ... sessionId), so the resolver itself is fine; something earlier in interactive init stomps the env var. Resolver is byte-identical across 2.1.212 / 2.1.214 / 2.1.215; the regression is in whatever writes the env.
5. Not agent-teams related: no team context (--team-name unset, no ~/.claude/teams), no tmux.

Expected

Interactive sessions honor CLAUDE_CODE_TASK_LIST_ID as documented (interactive-mode docs, "Task list" section), matching headless behavior.

Impact

No way to give concurrent interactive sessions in one repo separate persistent task lists. Related: #78874 (worktree-shared task state, no opt-out).

Repro

cd ~/some-repo
CLAUDE_CODE_TASK_LIST_ID=some-repo-abc123 claude
# in the session: create a task, then:  echo $CLAUDE_CODE_TASK_LIST_ID   -> "some-repo"
# ls ~/.claude/tasks/   -> task written to some-repo/, some-repo-abc123/ never created