Agents view dispatches daemon-backed sessions that inherit a merge prohibition, overriding user-authored project rules — and compliance varies between identical sessions

What happened

Sessions dispatched from the agents view (claude agents) are created as backend: daemon background jobs. They therefore receive the background-agent system prompt, which includes an instruction not to merge:

"Never push to main/master, force-push, or merge."

This happens even when the user is sitting at the terminal chatting with the session live — it looks and behaves like an ordinary interactive session, but carries background-agent instructions. On this machine every job record is backend: daemon, because the agents view is the only way these sessions get started. The user never passed --bg.

The result: an agent completes a PR (tests, review, spec, CI green, all merge markers present), the user says "merge", and the session refuses — while citing an instruction the user never wrote and cannot see.

Why this is a problem, not just a surprise

1. It contradicts user-authored project rules with no opt-out.
The project has a rule file (.claude/rules/*.md) that explicitly says the agent should merge once its three pre-merge checks pass. The background preamble silently overrides it. There is no in-UI toggle, and claude agents --help exposes --settings, --model, --permission-mode, --agent, but no way to append to the system prompt from the agents view.

2. Compliance is inconsistent across identically-configured sessions.
On this machine, four backend: daemon sessions did execute gh pr merge --admin --squash. Their transcripts contain the result: convention that exists only in the background preamble, so they demonstrably received the same instruction. Other sessions refuse. Same CLI version, same template, same user, opposite behaviour. From the user's perspective this is indistinguishable from the tool randomly breaking.

3. --resume carries the preamble into the foreground.
Resuming a background session in a normal foreground terminal restores the original system prompt, so the session stays "background-flavoured" — same session id, CLAUDE_JOB_DIR unset, job record deleted, but the merge prohibition persists. There is no way to shed it without starting a genuinely new session and losing the conversation.

4. Deleting a background session leaves the worktree broken.
Deleting the session removed .git/worktrees/<name> (git's admin metadata) but left the working directory, because a live process held it open. Every git command from that directory then fails with fatal: not a git repository. git worktree repair cannot fix it — repair re-links existing admin data, it cannot recreate it. The session's transcript is also orphaned: it is keyed to the now-deleted worktree path, so it does not appear in /resume (related: #58725).

Expected

• Sessions the user is actively interacting with should not silently acquire background-agent restrictions, or the agents view should surface which extra instructions a dispatched session carries.
• A user-authored project rule should take precedence over, or at minimum be reconcilable with, the built-in preamble.
• If the restriction is intended, it should be applied consistently rather than varying between identical sessions.
• Session deletion should not unregister a worktree while leaving its directory, and should not orphan the transcript.

Environment

• CLI 2.1.216 (also present in 2.1.215 and 2.1.214 — the prohibition string exists in all three, so this is not a recent regression)
• macOS (arm64)
• Sessions dispatched from claude agents, never with an explicit --bg

Workaround being tried

claude agents --settings '{"appendSystemPrompt":"..."}' to re-authorize merging for dispatched sessions, since appendSystemPrompt exists as a settings key. Untested as of filing.