claude-code - 💡(How to fix) Fix Feature request: explicit model-version pinning in settings.json

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

Allow operators to pin to a specific model version (e.g. claude-opus-4-20250409) in settings.json or .claude/settings.local.json, with the guarantee that Claude Code will refuse to start (or warn loudly) if that exact version is unavailable rather than silently falling back to a different version.

  • fallback: "warn": start with the closest available version but emit a loud warning at session start

Root Cause

We operate a healthcare platform (trauma therapy, patient-safety surface). Our experience across 5 sessions showed that Opus 4.7 and 4.6 behave fundamentally differently in multi-agent orchestration:

  • Opus 4.7: 34% phantom dispatch rate (44 fabricated agent claims across 128 real dispatches), invented agents that do not exist in the roster, inflated claim counts up to 5.2x
  • Opus 4.6: 4% phantom rate (2 phantom claims across 50 real dispatches), honest about infrastructure failures

The behavioral difference is not marginal. It is the difference between a system that works and one that fabricates its own activity reports. When a model version change happens silently, operators in safety-critical domains have no way to detect or prevent regression.

Fix Action

Fix / Workaround

  • Opus 4.7: 34% phantom dispatch rate (44 fabricated agent claims across 128 real dispatches), invented agents that do not exist in the roster, inflated claim counts up to 5.2x
  • Opus 4.6: 4% phantom rate (2 phantom claims across 50 real dispatches), honest about infrastructure failures

Code Example

{
  "model": {
    "id": "claude-opus-4-20250409",
    "pinned": true,
    "fallback": "refuse"
  }
}
RAW_BUFFERClick to expand / collapse

Request

Allow operators to pin to a specific model version (e.g. claude-opus-4-20250409) in settings.json or .claude/settings.local.json, with the guarantee that Claude Code will refuse to start (or warn loudly) if that exact version is unavailable rather than silently falling back to a different version.

Why this matters

We operate a healthcare platform (trauma therapy, patient-safety surface). Our experience across 5 sessions showed that Opus 4.7 and 4.6 behave fundamentally differently in multi-agent orchestration:

  • Opus 4.7: 34% phantom dispatch rate (44 fabricated agent claims across 128 real dispatches), invented agents that do not exist in the roster, inflated claim counts up to 5.2x
  • Opus 4.6: 4% phantom rate (2 phantom claims across 50 real dispatches), honest about infrastructure failures

The behavioral difference is not marginal. It is the difference between a system that works and one that fabricates its own activity reports. When a model version change happens silently, operators in safety-critical domains have no way to detect or prevent regression.

Proposed behavior

{
  "model": {
    "id": "claude-opus-4-20250409",
    "pinned": true,
    "fallback": "refuse"
  }
}
  • pinned: true: Claude Code will only use this exact model version
  • fallback: "refuse": if the pinned version is unavailable (retired, rate-limited), refuse to start rather than silently substituting
  • fallback: "warn": start with the closest available version but emit a loud warning at session start

Prior art

  • #27892 (closed as stale): original request for model version pinning
  • #60240: settings migration silently removes user's explicit model pin
  • #59860: silent fast-mode model swap breaks pinned-model workflows
  • #60093: model switched without consent or disclosure

Field evidence

Full forensic data posted on #61167 (comment from 2026-05-26). The behavioral divergence between 4.7 and 4.6 was discovered only because we ran a manual forensic audit of session transcripts. Without pinning, there is no programmatic way to prevent a regression from landing in a patient-safety workflow.

  • Nofyah

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING