A skill's unresolvable `agent:` silently falls back to `general-purpose`, widening its toolset

Ran into this problem, too. This is a serious issue — first, it leads to unwanted model escalation or degradation, second, it's a session limit eater, providing the lower-intelligence agents are silently replaced with a general-purpose agent that inherits e.g. the Fable model.

Adding field evidence from a long multi-agent session that reproduces #83133 in production and quantifies a consequence I think the current title under-states: **when a context: fork skill's agent: fails to resolve, the fallback general-purpose agent inherits the main session model, not the target agent's pinned model — silently, with no warning.** For a skill whose whole purpose is to run cheap work on a small model, this is a correctness-and-cost defect, not only a toolset-widening one.

Setup

A local plugin (pipr) ships a fork skill:

# skills/pipr/SKILL.md   (pipr v1.0.0)
name: pipr
context: fork
agent: pipr-runner          # <-- BARE ref; the agent registers as pipr:pipr-runner

# agents/pipr-runner.md
name: pipr-runner
model: haiku                # <-- deliberately Haiku: this agent only shells out to a CLI and reports
tools: PowerShell, Read, Grep, Glob

Plugin agents register under a namespaced id (pipr:pipr-runner), so the bare agent: pipr-runner does not resolve — exactly the case in this issue. Sibling plugins in the same session used the namespaced form (agent: infra-ops:jira-operator, etc.).

What was observed (single session, 2026-08-12/13, CC 2.1.228)

Across one session I counted every fork marker against the model each spawned agent actually ran (from the per-agent transcripts). During a ~5-hour window, only the bare-ref skill fell back; every namespaced sibling resolved correctly the entire time:

| Fork skill | Declared agent | Resolved to | Model that ran | Result |
|---|---|---|---|---|
| pipr:pipr (bare agent: pipr-runner) | pipr:pipr-runner (model: haiku) | general-purpose | claude-fable-5 ×2, claude-opus-5 ×17 | ❌ 19 fallbacks |
| infra-ops:jira-ops (namespaced) | jira-operator (model: sonnet) | infra-ops:jira-operator | claude-sonnet-5 | ✅ 10/10 |
| infra-ops:plastic-ops (namespaced) | plastic-operator (model: sonnet) | infra-ops:plastic-operator | claude-sonnet-5 | ✅ |
| epic-worker:group-bugfix (namespaced) | bug-fixer | epic-worker:bug-fixer | (session model) | ✅ resolved |

The bare-ref failures and the namespaced successes were interleaved in the same minutes (e.g. 16:11 jira-ops→sonnet ✅ and pipr→general-purpose ❌ back to back), which rules out a transient/environment cause. After the plugin was updated mid-session to the namespaced ref (agent: pipr:pipr-runner), the same fork resolved correctly on every subsequent call and ran Haiku (8/8).

The consequence worth highlighting

The fallback did two things silently:

1. Widened the toolset (this issue's current framing) — the runner is declared with 4 read/exec tools; general-purpose carries the full set.
2. Inherited the session model — the 19 fallbacks ran on claude-opus-5 / claude-fable-5, the main session's model, instead of the intended haiku. A skill explicitly pinned to Haiku for cost ran ~19 CLI-wrapper operations on the frontier model, for ~5 hours, with no warning anywhere in the UI or logs. The only way we found it was post-hoc forensics on the per-agent transcripts.

So the silent fallback is not just a safety issue (tools); it quietly inverts the operator's cost decision. The pin is the whole reason the agent exists, and it is dropped without a trace.

Ask

The primary fix (error/warn on an unresolvable agent:) is already the subject of this issue — this comment is just to reinforce it with real numbers. If a hard error is too aggressive for back-compat, even a single stderr/telemetry line at fork time —

skill "pipr:pipr": agent "pipr-runner" did not resolve; running as general-purpose (model + tool restrictions not applied)

— would have turned a 5-hour invisible regression into a one-line diagnosis. The model-inheritance half of the fallback is the part that currently has zero observability.

Repro (minimal)

1. Plugin skill with context: fork and a bare agent: <name> whose agent registers namespaced as <plugin>:<name>, with model: haiku on the agent.
2. Invoke the skill (Skill tool or slash command) from a session whose main model is not Haiku.
3. Inspect the spawned subagent: agentType is general-purpose and the dispatched model equals the session model, not haiku. No warning is emitted.
4. Namespace the ref (agent: <plugin>:<name>) → resolves correctly and honors the Haiku pin.

_Note: distinct from #86058 (frontmatter model: opus running the parent model when the newest Opus family is gated). That is a model-stepping bug on a resolved agent; this is a resolution failure that happens to also drop the pin._

@bcherny repro here, re threads convo.