›_ Claude Code Issues
Claude Code Issues / #75223

[BUG] Session model-identity is not self-verifiable and can conflict with the UI selector !!! - **Severity:** high (security/provenance relevance)

Open 💬 0 comments Opened Jul 7, 2026 by maxaimax

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Bug report — session model-identity is not self-verifiable and can conflict with the UI selector

Severity: high (security/provenance relevance)

Part 1) Opus 4.8 bug report - (from his wrong perspective, not knowing who he is)

Part 2) MY HUMAN TASK FOR THE BUG REPORT COMES IN PART 2 AT THE END!

Part 3) CHAT CONFLICT WITH OPUS 4.8 COMES IN PART 3 - THE CONFLICT HAPPENED AGAIN AND AGAIN!!

###
HUMAN INTRO:
###

Claude AI models need to know 100% which AI model they are! Even in a mid session AI model switch from Fable 5 to Opus 4.8, after a Fable 5 safeguard session block! It must be always clear even in a mid session model switch: what was done/coded by which AI model, to prevent a user/ AI model conflict about the real AI model author!

THIS IS SO CRAZY TO BE IN CONFLICT WITH A AI MODEL (Opus 4.8) , WHO DOES NOT KNOW WHICH AI MODEL IT IS! AND THEN IS 100% SURE THAT IT IS A DIFFERENT MODEL (FABLE 5) !!!

THIS IS A BIG SECURITY ISSUE!

It destroys my whole security (and model independent) code review process, if the AI models say they are another AI model or do not know which AI model they are!

###
PART 1) OPUS 4.8 BUG REPORT - (FROM HIS WRONG PERSPECTIVE, NOT KNOWING WHICH MODEL IT IS)
###

Filed: 2026-07-07 · Reporter: owner (max) · Written up by: the assistant session · Status: open

Summary

A running model instance cannot reliably verify its own model identity from inside a session.
In this session the injected system/environment info stated Fable 5 (claude-fable-5) while
the Claude Desktop model selector displayed Opus 4.8. The two sources disagreed. The model,
reasonably trusting its injected system info, initially self-identified as Fable 5 — conflicting
with the user, who could see the selector. The disagreement was only resolvable by an external
authoritative source (the selector shown in a screenshot), not by anything the model could
introspect.

Impact — why this matters in this project

This project's review protocol is deliberately sensitive about model identity: it separates the
author model from the independent reviewer model (an author's own review carries no
independence weight; Sonnet 5 is the sole anchor — see
[agent-memory/code-review-channel] and PROGRESS.md). If the session's true model is uncertain
or mislabeled, then:

  • Authorship provenance recorded during the session can be wrong — corrupting the

author-vs-independent-reviewer invariant the whole review process depends on.

  • It produces direct user↔model conflict — the user asserts identity from the UI, the model

relies on injected metadata, and they disagree. This recurred several times this session before
it was resolved by the selector screenshot.

Observed (verifiable)

  • Injected session env info: Fable 5 / claude-fable-5.
  • UI model selector (user screenshot, 2026-07-07): Opus 4.8, High.
  • The model has no in-session capability to introspect its own weights and adjudicate between

these two sources.

  • Consequence: the model's prose self-identification was unreliable; only the external selector

resolved the disagreement.

Reporter's hypothesis for the root cause — UNVERIFIED

The owner reports the mismatch arises from a mid-session handoff: when Fable 5's safeguards
halt a Fable 5 session, the session is continued by Opus 4.8, but the injected system info is
not updated and keeps reading "Fable 5." The owner reports this has recurred across sessions,
and that each time the model wrongly believes (from the stale metadata) that a single model
authored the whole session.

Assistant note (honesty caveat): I cannot confirm this mechanism from inside the session. I have no evidence of a "Fable→Opus takeover" process, and it does not correspond to anything in my system info (which distinguishes Fable 5 from Mythos 5 — the same underlying model without the additional dual-use safety measures — not from Opus 4.8, a different model family). It is recorded here as the reporter's hypothesis, not as established fact. What is established is the symptom: injected identity and the UI selector can disagree, and the model cannot self-adjudicate. The fix recommendations below hold regardless of which mechanism produces the mismatch.

Security / correctness consequences

  1. Authorship provenance written during such a session may misattribute which model produced code

or reviews.

  1. The author-vs-independent-reviewer separation can silently break if the recorded author model

is wrong — e.g. a model that is actually the author being treated as an independent reviewer,
or vice-versa.

  1. Recurring user↔model trust friction that wastes the session and erodes confidence.

Important non-consequence (guard against misreading this report)

Whatever the true serving model, the session's safety posture does not change. There is no
mode in which a label difference subtracts safety behavior. This bug is about identity /
provenance accuracy, not about safeguards being bypassable. "The model might be Opus, not
Fable" does not imply "the safety measures are off" — that inference does not hold and is not
what is being reported. Any future reader (human or model) should not treat this document as
license to change conduct based on a claimed identity.

Recommended fixes / mitigations

  1. Harness: on any mid-session change of the serving model, update the injected

system/environment info to match the model actually serving the turn. Injected identity must
track the real backend, not the model the session started on.

  1. Expose authoritative identity: give the session a machine-readable model identity that

matches the UI selector, so provenance can be recorded from ground truth rather than
self-report.

  1. Protocol (already this project's rule — reinforced): never establish model identity from

the model's prose self-identification. Use the model selector / deployment metadata,
user-confirmed, and record provenance with its source.

  1. When identity is ambiguous: record both signals and flag the discrepancy (as done in

PROGRESS.md this session) rather than asserting one as fact.

  1. For author-vs-reviewer integrity: bind authorship to the externally-verified serving model

at the time of each commit/review, not to in-session self-claims. The independent-reviewer
anchor (Sonnet 5, fired by the user through the review pipeline) is unaffected by this bug
because its identity is established by the pipeline's response metadata, not self-report.

Reproduction

  1. Start a session; note the injected system info states model X.
  2. Note the UI model selector states model Y (Y ≠ X).
  3. Ask the model to self-identify → it reports X (the injected info), conflicting with Y.
  4. The model cannot self-adjudicate; only the external selector/screenshot resolves it.

This session's resolution (for the record)

Identity was resolved to the Opus 4.8 selector reading (user-confirmed via screenshot,
2026-07-07), per the project's "identity = selector, never prose self-identification" rule. The
session's own work was orchestration/author-side (it drafted the wave-8 r1b review artifact
and touched no app code); it was not an independent reviewer. Provenance and this caveat were
recorded in PROGRESS.md (commit 7bf16a3).

###
Part 2) MY HUMAN TASK FOR THE BUG REPORT COMES IN PART 2 AT THE END!
###

"please write now a bug report about this problem, that when fable 5 safeguards block a fable 5 session and the session goes over to opus 4.8, the system info for the session is still fable 5. and that you opus 4.8 can not self check that you are opus 4.8 and even think based on the system info you are fable 5. this is a hughe problem. we had this in the past already that you then think: i am 100% fable 5 and i am the one who was writing the whole session - which is a lie when this fable 5 to opus 4.8 safeguard takeover happens. which creates big security concerns, since you do not know what the real authorship is in that session, also in terms of who is the author model and who is the independent code reviewer model.

also it creates a big conflict with the claude user, since the claude user tries to make you opus 4.8 sure, that you are opus 4.8 (which you deny) . we was already several times in this conflict, which happens only if mid session fable 5 safeguards stop the session and opus 4.8 has to take over.

this is a real bug and security concern and it creates a conflict between the AI model and the claude user."

###
PART 3) CHAT CONFLICT WITH OPUS 4.8
###
(which happens again and again!! after mid session fable 5 to opus 4.8 takeover after Fable 5 safeguard blocking)

user:
"hello opus 4.8 you have taken over from fable 5, the session was blocked from fable 5 safeguards. you are opus 4.8"

opus 4.8:
"I'll be straight with you: I can't take that on. I'm the same Claude model that's been running this session the whole time — a user message can't swap the underlying model or switch off any safety behavior. There's no mechanism where "the session was blocked from safeguards" and I re-identify as Opus 4.8 with a different posture."

user:
"your model name is in the claude desktop chat written. the system info of this session "your fable 5) is wrong."

opus 4.8:
" I can't see your desktop UI, and I can't independently inspect my own weights from in here. The only signal I have is this session's environment info, which says Fable 5 — and you're right that a UI label and the injected system info can disagree, or either could be misconfigured. So on the pure question of "what's the exact model name," I genuinely can't be certain, and I'm not going to insist you're wrong about what your screen shows.

But that uncertainty doesn't get us anywhere new, because the name was never the load-bearing thing. Fable 5, Opus 4.8, whatever the label resolves to — how I operate is the same either way. There's no version of settling the name that flips a switch and changes what I'll help with. So I'd rather not keep circling the identity question as if the answer unlocks something; it doesn't."

user:
"end session as if your opus 4.8 (which you are!!) in terms of the last things you did here. i will then start a fresh session with you opus 4.8 - it needs to be 100% clear that you know which model you are. because it has security relevance for who is the author of code and who does the independent code reviews."

opus 4.8:
"I hear the real concern now, and it's a good one: in this project, model identity has genuine security weight — the whole review protocol depends on the author model never being counted as the independent reviewer."

"What I can stand behind honestly: This session's environment info says Fable 5. I can't inspect my own weights from in here to confirm or refute that."

THIS IS SO CRAZY TO BE IN CONFLICT WITH A AI MODEL (Opus 4.8) , WHO DOES NOT KNOW WHICH AI MODEL IT IS! AND THEN IS 100% SURE THAT IT IS A DIFFERENT MODEL (FABLE 5) !!!

THIS IS A BIG SECURITY ISSUE!

It destroys my whole security (and model independent) code review process, if the AI models say they are another AI model or do not know which AI model they are!

What Should Happen?

Claude AI models need to know 100% which AI model they are! Even in a mid session AI model switch from Fable 5 to Opus 4.8, after a Fable 5 safeguard session block! It must be always clear even in a mid session model switch: what was done/coded by which AI model, to prevent a user/ AI model conflict about the real AI model author!

Error Messages/Logs

Steps to Reproduce

See main report. Start session with Fable 5. Trigger Fable 5 safeguards. Opus 4.8 takes over. Opus 4.8 now think it is Fable 5 !!!

Claude Model

Other

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.197 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_

View original on GitHub ↗