Explicit subagent model pin is lost when a background agent is woken or resumed — agent continues on the session model

This looks like a model-authority continuity bug, not only a routing preference.

For an explicitly pinned background agent, I would expect the model decision to be represented as durable authority for that delegated run:

• parent session id and session model
• delegated agent id and requested model
• configured model source: explicit pin, workflow default, env default, or session fallback
• effective model at launch, wake, resume, and workflow fanout
• fanout count and projected budget scope when knowable
• terminal outcome: preserved, warned, blocked, downgraded, or user-approved override

The fail-closed cases matter as much as the happy path:

• if a pinned agent wakes on a different model, stop before continuing and emit model_authority_mismatch
• if workflow fanout would inherit a high-cost session model, show the effective model and fanout scope before launch
• if policy or budget cap would be crossed, record budget_hold or downgraded_with_approval rather than silently running

That gives a concrete regression boundary: delegated work can continue only when the effective model still matches the model authority the user granted for that agent or workflow stage.

Boundary: architecture and regression-test feedback only; no claim about running Claude Code, implementation correctness, Anthropic alignment, adoption, integration, customer interest, official alignment, or Neura usage.

Reproduced on v2.1.206 (macOS, darwin/arm64), with one detail that may widen the scope: the pin was dropped by a parent-session resume while the background agent was still mid-task, with no SendMessage and no wake-from-child-completion involved.

Setup: session main model claude-fable-5, background subagent launched via the Agent tool with model: "opus" (subagent_type: "general-purpose", run_in_background: true).

Observed, from the task's transcript JSONL (ordered "model" stamps on assistant messages):

7 turns  claude-opus-4-8     <- launch through normal operation
7 turns  claude-fable-5      <- everything after the parent session was resumed

The flip aligns exactly with a SessionStart:resume event in the parent session; the agent itself was never messaged. It continued executing the same task, silently, on the session model until we noticed and killed it.

Two implications consistent with this report:

• The re-resolution to the session model happens at continuation boundaries generally, not just SendMessage/wake: a parent-session resume is enough to flip an in-flight background agent.
• Because the TUI badge does not reflect the resolved model (#76343), the flip is invisible unless you grep the transcript. Our detection was grep -o '"model":"[^"]*"' <task output file> | sort | uniq -c run after the resume.

Workaround we've adopted: treat every pinned background agent as suspect after any session resume (re-grep, kill and respawn on flip), and never resume a pinned agent for work that must stay on the pinned model.

Still reproduces on v2.1.207 (build 2026-07-10), macOS 15 / Darwin 25.5.0, Max subscription, main loop on claude-fable-5 — observed in an organic session, not a probe:

• A general-purpose subagent was launched via the Agent tool with an explicit model: "sonnet" pin. Its transcript shows 14 assistant turns on claude-sonnet-5 (first at 2026-07-11T16:06:42Z).
• The agent had spawned background work of its own; when a task notification woke it ([SYSTEM NOTIFICATION - NOT USER INPUT] This is an automated background-task event… in its transcript), every subsequent turn — 23 of them, first at 2026-07-11T16:12:49Z — ran on claude-fable-5.
• Same single agent transcript (subagents/agent-*.jsonl), so this is a mid-lifetime re-resolution on the wake boundary, not a new agent inheriting the session model.
• Of 20 subagents in the session, this was the only one continued across a background-notification boundary, and the only one that flipped — the other 19 (including 8 sonnet-pinned agents that ran start-to-finish without a wake) all stayed on their pinned model.

Matches the reported mechanism exactly: the pin holds for the initial run and is lost on the wake/resume re-resolution.