[BUG] Desktop app: interactive sessions intermittently start in the shared base checkout instead of a per-session worktree (isolation configured)

Environment

• macOS 26.5.1 (Darwin 25.5.0), Claude Code desktop app (CLI reports 2.1.121)
• Settings → Local sessions: Worktree location = "Inside project (.claude/worktrees/...)", Branch prefix = "claude"
• Project: a git repo used concurrently by multiple interactive desktop-app sessions

Summary

With interactive worktree isolation enabled, some new sessions are never given a per-session worktree and instead run directly in the shared base checkout. The failure is intermittent: on the same day, in the same project, some sessions get a proper .claude/worktrees/<name> worktree while others land in the base checkout. A session that lands in the base checkout inherits whatever branch the folder was last left on.

Observed (2026-07-11, three concurrent sessions on one project)

git worktree list from the base checkout (identifiers genericized):

<repo>                                    aaaaaaa [feature-branch-a]        <- base checkout; an interactive session ran HERE
<session-scratchpad>/session-b-wt         bbbbbbb [claude/session-b-...]    <- correctly isolated session
<repo>/.claude/worktrees/session-c-...    ccccccc [claude/session-c-...]    <- correctly isolated session

In the affected session, git rev-parse --show-toplevel returns the base repo path and --git-dir == --git-common-dir (i.e. not a linked worktree).

Impact

• The session inherits a stale branch left behind by a previous session (a day of unrelated work from multiple sessions piled onto a leftover feature branch before anyone noticed).
• "New session on main" then hits: "Uncommitted changes on <branch> — N other sessions are using this folder. Switching branches will affect them too."
• Any branch switch in the base checkout drags every other non-isolated session with it.

First written up internally on 2026-06-19 (same symptoms, app version 1.14271.0 at the time); still reproducing on current versions.

Expected

Every interactive session gets its own worktree when worktree isolation is configured — or, if worktree creation fails, the session refuses to start in the shared checkout (or at minimum warns loudly), rather than silently falling through.

Possibly related

• #74089 (worktree removed mid-session, git falls through to parent checkout — Windows; different mechanism, same end state)
• #76415 (worktree setting not affecting interactive session worktree creation)