[Bug] Remote-control sessions incorrectly inherit multi-agent worktree isolation defaults

Bug Description
Title: Remote-control/daemon sessions force git worktree isolation based on origin — unprompted branch creation AND a stale-base data-loss footgun

Summary

Enabling /remote-control on an ordinary interactive terminal session routes it through the daemon and labels it a background job. Background-job mode (a) injects an instruction to call EnterWorktree before any code change AND (b) enforces a guard that REFUSES edits to the shared checkout unless the session is in a worktree. The agent therefore creates a git worktree + branch with no user request, in a single-user single-repo session.

Worse: the worktree is created with baseRef "fresh" (branched from origin/<default-branch>), not from local HEAD. When the local branch has unpushed commits, the worktree is silently based on a STALE remote tree. In our case local main was 52 commits ahead of origin/main (an entire unpushed work phase). The forced worktree contained months-old code; editing/committing in it would have produced a branch forked from a stale base that, on merge, could silently revert or diverge from all current local work.

This is the core design error: terminal use and remote-control both exist to work LOCALLY. Treating a remote-controlled local session like a detached cloud agent that should isolate-and-sync-from-origin inverts the user's intent. Remote-control means "mirror this one session to my phone/web," not "multiple agents will edit this repo" and not "this work should be based on origin."

Environment

• Claude Code v2.1.159, Opus 4.8
• Launched normally: claude in terminal -> /start
• /remote-control is active (bridged to claude.ai/code + phone)
• Session daemon-backed ("backend": "daemon" in job state.json), "intent": "/start"
• Repo: local main 52 commits ahead of origin/main (unpushed local work)

Repro

1. In a repo with unpushed local commits, start a normal terminal session with remote-control active.
2. Ask the agent to make any code change.
3. The agent's context contains a "# Background Session" block instructing EnterWorktree before editing; a guard also blocks edits to the shared checkout.
4. The agent creates a worktree + branch unprompted.
5. The worktree is branched from origin/main (baseRef "fresh") -> it does NOT contain the unpushed local commits -> the agent is now editing stale code.

Expected

• Remote-control / phone-mirroring must NOT put a session into background-job / multi-agent / isolate-from-origin mode.
• Worktree isolation should be opt-in (user asks, or a project rule requires it), never inferred from remote-control.
• If isolation ever IS applied to a local session, it must branch from local HEAD, never from origin, so unpushed work is preserved.

Actual

• Remote-control -> daemon-backed -> tagged a job -> background-job instructions + edit guard -> agent auto-creates a worktree+branch based on origin -> stale tree when local work is unpushed.

Impact

• Surprising, unrequested git state (stray branches/worktrees).
• DATA-LOSS RISK: isolation based on origin silently discards/diverges from unpushed local work (52 commits in our case).
• Conflicts with project conventions (CLAUDE.md "commit directly to main").
• Erodes trust: users reasonably expect worktrees to be user-initiated, and local sessions to be local-first.

Suggested fix (in priority order)

1. Decouple remote-control from background-job/isolation mode entirely — mirroring a session must not change its execution or VCS semantics.
2. Never auto-isolate a local (terminal/remote-controlled) session; make worktree isolation strictly opt-in.
3. If isolation is applied, default baseRef to local HEAD, never origin — losing unpushed work must be impossible by default.
4. Make both behaviors configurable per repo in settings (e.g. "worktree": {"bgIsolation": "none"}) and document them prominently. (The bgIsolation:none escape hatch exists but is undiscoverable until an edit is blocked.)
5. At minimum, the background-mode instruction should defer to project CLAUDE.md conventions when they conflict, and warn loudly when a worktree base is behind local HEAD.

Environment Info

• Platform: darwin
• Terminal: xterm-256color
• Version: 2.1.159
• Feedback ID: 1090b12f-17de-4a1d-ac9d-6aebe5b4be22

Errors

[]