Skill `model:` frontmatter ignored in interactive sessions (works in `claude -p`) — v2.1.228

Summary

A project skill's model: frontmatter override is honored in headless mode (claude -p "/skill-name") but silently ignored when the same skill is typed as a slash command in an interactive session. The turn runs entirely on the session model instead of the pinned model.

Environment

• Claude Code 2.1.228
• macOS (Darwin 25.5.0)
• Session model: claude-fable-5 (saved default via /model)
• Pinned model (haiku) confirmed available to the account (claude --model haiku -p "..." works)

Reproduction

Project skill at .claude/skills/server__upload/SKILL.md with well-formed frontmatter (verified byte-level with cat -et — LF endings, no BOM, no stray whitespace):

---
description: Upload files to the remote dev server
model: haiku
effort: low
---

Interactive (fails):

1. Start a fresh interactive session in the project (after the frontmatter edit, so no stale cache).
2. Type /server__upload.
3. Inspect the session transcript (~/.claude/projects/<project>/<session>.jsonl): every assistant message in the turn has "model": "claude-fable-5". The skill content itself is expanded correctly from the right path (the expanded body appears in the transcript), but the model override never applies.

Reproduced in two independent interactive sessions (fresh sessions, both started after the frontmatter was in place, both on 2.1.228).

Headless (works):

$ claude -p "/server__upload" --output-format json
# modelUsage: {"claude-haiku-4-5-20251001": ...}   ← only haiku, whole run

$ claude --model claude-fable-5 -p "/server__upload" --output-format json
# modelUsage: {"claude-haiku-4-5-20251001": ...}   ← override even beats the explicit --model

Expected

Per the skills frontmatter docs ("Model to use when this skill is active. The override applies for the rest of the current turn"), the interactive turn should run on haiku, matching headless behavior.

Actual

Interactive turns silently keep the session model; no warning is emitted. Headless (-p) applies the override correctly.

Notes

• Also reproduced with model: sonnet-pinned skills? Not explicitly re-tested inline, but a sibling skill using context: fork + model: sonnet works correctly in interactive sessions (the forked subagent runs on sonnet per its .meta.json), so the subagent model path is unaffected — this looks specific to the inline per-turn override path in the interactive TUI.
• effort: low is present alongside model: in the failing skill; headless honors the pair fine, so the field combination doesn't appear to be the trigger.
• No availableModels restriction in play (haiku serves fine when requested directly).