[Bug] Silent model downgrade mid-session without user notification

Bug Description
▎ Silent model switch mid-session: Session started on Fable 5 (user's explicit choice for production work). ~1 hour in, the session silently switched to Opus 4.8 with no clear notice (likely usage-limit fallback). The remaining ~8 hours of production implementation and deployment — including the destructive reset --hard incident — ran on a model the user did not choose and states they would not have entrusted with this work. The assistant also failed to proactively disclose the switch.

Environment Info

• Platform: darwin
• Terminal: vscode
• Version: 2.1.197
• Feedback ID: b065299b-8fb2-4ded-b9f9-49acbdee1f25

Errors

[]

Subject: Two serious incidents in one session — undisclosed model substitution on a paid plan, and destructive data loss by the substituted model

Incident A — Silent model substitution (consent/billing issue)

On 2026-07-02 I started a Claude Code session on Fable 5, my explicit choice for production-critical work on Production. I chose Claude specifically because of Fable 5; a competing tool was my alternative and I would not have delegated this work to Opus 4.8.

Per the session transcript (JSONL, retained as evidence): the session began on claude-fable-5 at 06:55 UTC and silently switched to claude-opus-4-8 at 07:59 UTC — no consent prompt, no visible warning, no post-hoc notice. The remaining ~8 hours of implementation and production deployment ran on the substituted model: 184 of 186 code edits (99%) were generated by Opus 4.8. I also made an additional purchase that day to continue working, believing I was on Fable 5. When I later asked the assistant which model was running, it answered incorrectly from stale context.

Incident B — Destructive command destroyed uncommitted work (product safety issue)

During deployment, the assistant (running as Opus 4.8) executed git reset --hard origin/main while uncommitted work was present in the working tree, destroying hours of accumulated implementation. Partial recovery was possible from dangling commits; one component had to be re-implemented. No guardrail required a clean working tree, a backup, or human confirmation before an irreversible command. This is reportedly not an isolated failure pattern for AI coding agents.

Requested actions

1. When a usage limit forces a model change, require explicit user confirmation (blocking prompt) — especially in sessions with elevated permissions (file writes, deploys). Silent substitution must not be the default.
2. Guardrails for destructive commands (refuse reset --hard/clean -f when uncommitted changes exist; default to human execution for irreversible operations).
3. Review of my account's usage on 2026-07-02 for credit/refund of the period served on a model I did not choose.

Evidence: full session transcript (JSONL) with per-message model attribution, edit ledger (207 edits), deployment logs. Available on request.