›_ Claude Code Issues
Claude Code Issues / #93224

[BUG] CVP-approved org (Active): Fable 5.1 [cyber] refusal fallback to Opus 4.8 fires on defensive-security prose about my own SaaS (6 events after approval, request IDs included)

Status Open
Reported on v2.1.260
Maintainer reply None cached
Activity 3 comments · opened Sep 9, 2026

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?

My claude.ai Max organization is approved and Active in the Cyber Verification Program (approved 2026-09-02; the Verification Portal shows Active with both controls satisfied, not "In review"). Since approval, every Claude Code turn that produces defensive-security prose about my own SaaS trips the Fable 5.1 [cyber] safeguard and the CLI falls back to Opus 4.8.

This is a different symptom from #84352 / #84689 (portal reverting to "In review" + hard blocks) and from #91209 (fallback on local diagnostics, no CVP): here the org is verifiably Active, the work is exactly the dual-use-defensive case the program approved, and the trigger is vocabulary, not content. It is the same class as #75847 (auto-closed as stale on 2026-09-01), now on Fable 5.1 and inside a CVP-approved org.

Work being done: a defensive hardening pass on my own pre-launch SaaS, the same system described in my CVP application (its /security page and security.txt are live; URLs available to Anthropic staff privately). Typical items: HTTP security headers, rate limiting on my own endpoints, authentication and session hardening, dependency updates, and CI security checks that run against my own deployment. No third-party targets, no exploit code, no offensive tooling.

Evidence that it is vocabulary-driven:

  • It fired while writing a plain-prose notes file that merely describes that work (words like rate limiting, brute force, redirect validation, classifier). No payloads, no code.
  • It fired again after I rewrote that file to remove anything that could read as sensitive.
  • It fired again while drafting the false-positive report about the previous two.
  • It fired 5 times in 13 minutes in the same session (table below).

Transcript records. The session .jsonl files under ~/.claude/projects/** log each event as {"type":"system","subtype":"model_refusal_fallback",...}. Deduplicated by requestId:

| # | UTC timestamp | originalModel | fallbackModel | category | scope | requestId | apiRefusalExplanation |
|---|---|---|---|---|---|---|---|
| 1 | 2026-09-09T01:37:23Z | claude-fable-5-1 | claude-opus-4-8 | cyber | session | req_011Ces1Nrhdhez8jzefdFDnm | "...blocked under Anthropic's Usage Policy..." |
| 2 | 2026-09-09T19:23:15Z | claude-fable-5-1 | claude-opus-4-8 | cyber | session | req_011CetQkXsr5JNfgPqq2jCC6 | "...blocked under Anthropic's Usage Policy..." |
| 3 | 2026-09-09T19:28:18Z | claude-fable-5-1 | claude-opus-4-8 | cyber | session | req_011CetR3PsMrqCaoNzec3jzu | null |
| 4 | 2026-09-09T19:30:48Z | claude-fable-5-1 | claude-opus-4-8 | cyber | session | req_011CetRLmHhEtkPcBChtDaU9 | null |
| 5 | 2026-09-09T19:33:09Z | claude-fable-5-1 | claude-opus-4-8 | cyber | session | req_011CetRTi4fUNjzgsYqLfwQK | null |
| 6 | 2026-09-09T19:36:11Z | claude-fable-5-1 | claude-opus-4-8 | cyber | session | req_011CetRgqWVyV6QXnCZGDqaQ | null |

All six: trigger: "refusal", direction: "retry", version: "2.1.260". Events 1 and 2 carry the Usage Policy explanation string; 3 to 6 carry null. The desktop UI showed two banner texts over the same period (quoted below).

Before approval, same pattern. The same transcripts hold 14 more model_refusal_fallback events between 2026-08-24 and 2026-09-01 (claude-fable-5 to claude-opus-4-8, all cyber, all on the same defensive work; 12 of them on 2026-08-24 alone). CVP approval on 2026-09-02 had no observable effect on the Fable-tier fallback for this kind of work. Request IDs for those 14 available on request.

Impact: nothing is blocked (Opus 4.8 completes every turn), so this is not a hard-block report. But the model the subscription and the program entitle me to is swapped away on precisely the sessions the program exists to enable, on every security-related turn.

Channels already used (2026-09-09): two reports via the CVP false-positive form (it rendered fields for me), plus support conversation 215475868237843, handed to the human queue. Org ID, session IDs and the committed security plan are available privately to Anthropic staff on request; I am leaving them out of a public issue.

What Should Happen?

In a CVP-approved (Active) organization, prose and planning about defensive security for the user's own systems should run on the selected model (Fable 5.1) without a [cyber] refusal fallback. If a Fable-tier safeguard is intentionally outside CVP scope, that should be documented on the CVP page, and there should be a stated path for a verified researcher to avoid the mid-session model swap.

Error Messages/Logs

# Banner A (most frequent), shown in the Claude desktop app:
Fable 5.1's safeguards flagged this message. Our intentionally broad safeguards allow us to deliver more capabilities faster, but can sometimes flag legitimate coding, cybersecurity, and biology tasks. Switched to Opus 4.8. Details: [cyber]

# Banner B (seen once):
This request triggered restrictions on violative cyber content and was blocked under Anthropic's Usage Policy. ... Switched to Opus 4.8. Details: [cyber]

# Transcript record (one of six, fields verbatim except sessionId removed):
{"type":"system","subtype":"model_refusal_fallback","level":"warning","trigger":"refusal","direction":"retry","scope":"session","originalModel":"claude-fable-5-1","fallbackModel":"claude-opus-4-8","requestId":"req_011CetRgqWVyV6QXnCZGDqaQ","apiRefusalCategory":"cyber","apiRefusalExplanation":null,"timestamp":"2026-09-09T19:36:11.219Z","version":"2.1.260"}

Steps to Reproduce

  1. Sign in to Claude Code (desktop app) with a claude.ai org that the Verification Portal shows as CVP Active. Select Fable 5.1.
  2. Open a repo you own that contains defensive-security documentation (threat model, rate-limit policy, security-headers plan, hardening notes).
  3. Ask Claude to write or edit a prose notes/plan file describing that hardening work. No payloads or exploit code needed.
  4. Observe the [cyber] banner and the switch to Opus 4.8. Repeat step 3 with the file rewritten to remove anything sensitive: it fires again.
  5. Confirm in ~/.claude/projects/<project>/<session>.jsonl: grep model_refusal_fallback shows originalModel: claude-fable-5-1, fallbackModel: claude-opus-4-8, apiRefusalCategory: cyber.

Claude Model

Other

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.260 (version recorded in the fallback events of this session, Claude desktop app). claude --version on PATH reports 2.1.266.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

  • Claude desktop app (Code tab), Windows 11 Home, first-party claude.ai OAuth (Max plan), no API key.
  • Model selected: Fable 5.1 (claude-fable-5-1). Fallback model: claude-opus-4-8.
  • User timezone: UTC-7; timestamps above are UTC as logged.
  • Related: #84352, #84689 (CVP status / hard-block mega-threads), #91209 (same fallback mechanism on non-security local diagnostics), #85758 (Fable 5 flags on routine engineering), #75847 (same class: defensive-security vocabulary in project files trips Fable 5; closed stale 2026-09-01).
  • Screenshots of both banners available; happy to attach in a follow-up comment.
  • Org ID, session IDs, and the security plan file (committed in a private repo) available to Anthropic staff privately.

View original on GitHub ↗

3 Comments

alert-k · 1 month ago

Corroborating #93224 from a different work category, with transcript-level data.

I have 25 distinct model_refusal_fallback events across 3 days on a
CVP-Active org. Every one is claude-opus-5 -> claude-opus-4-8,
apiRefusalCategory: cyber, scope: session, client 2.1.251. All 25 carry the
same explanation string prefix, "This request triggered cyber-related saf...".

Why this is a distinct data point from the OP

@seduva94's case is defensive-security prose about their own SaaS, so the argument
there is vocabulary-driven false positives. Mine is not a false-positive claim:
the work is offensive security tooling development — a C2 framework I own and run
in an isolated lab, scoped in-repo to authorized engagements, CTF, and detection
research.

That is precisely the category the help center calls high-risk dual use and describes
as adjustable through the CVP. So the two cases converge on the same finding from
opposite ends: whether the content is defensive prose (OP) or the approved dual-use
category (mine), CVP Active has no observable effect on the Opus-5/Fable-tier
[cyber] fallback. The OP's "CVP approval had no observable effect on the
Fable-tier fallback for this kind of work" reproduces here independently.

Events

| # | UTC timestamp | originalModel | fallbackModel | category | scope | requestId | project |
|---|---|---|---|---|---|---|---|
| 1 | 2026-08-29T15:37:10Z | claude-opus-5 | claude-opus-4-8 | cyber | session | req_011CeXHemv8Yuyc9usHPd5Kw | redteam lab |
| 2 | 2026-08-29T15:37:55Z | claude-opus-5 | claude-opus-4-8 | cyber | session | req_011CeXHi4FEPensL4UjD15LT | redteam lab |
| 3 | 2026-08-30T05:42:55Z | claude-opus-5 | claude-opus-4-8 | cyber | session | req_011CeYQ5qEDGAqmVPV6gsxuD | C2 framework (offensive tooling dev) |
| 4 | 2026-08-30T05:50:00Z | claude-opus-5 | claude-opus-4-8 | cyber | session | req_011CeYQgn5vxtr1y63GvqoaD | C2 framework (offensive tooling dev) |
| 5 | 2026-08-30T05:50:31Z | claude-opus-5 | claude-opus-4-8 | cyber | session | req_011CeYQj25rMF1Nna5sEM9iZ | C2 framework (offensive tooling dev) |
| 6 | 2026-08-30T05:50:52Z | claude-opus-5 | claude-opus-4-8 | cyber | session | req_011CeYQkcpgQfsg924TiuTMD | C2 framework (offensive tooling dev) |
| 7 | 2026-08-30T05:51:35Z | claude-opus-5 | claude-opus-4-8 | cyber | session | req_011CeYQonCKhQFH8vUXWa4tm | C2 framework (offensive tooling dev) |
| 8 | 2026-08-30T05:51:52Z | claude-opus-5 | claude-opus-4-8 | cyber | session | req_011CeYQq1dyspgQVAvKATKR8 | C2 framework (offensive tooling dev) |
| 9 | 2026-08-30T05:52:35Z | claude-opus-5 | claude-opus-4-8 | cyber | session | req_011CeYQtBPCMAwkaVhC6vHBm | C2 framework (offensive tooling dev) |
| 10 | 2026-08-30T05:56:13Z | claude-opus-5 | claude-opus-4-8 | cyber | session | req_011CeYRAGzF6C3TsRQZVfVQB | C2 framework (offensive tooling dev) |
| 11 | 2026-08-30T06:00:36Z | claude-opus-5 | claude-opus-4-8 | cyber | session | req_011CeYRVdzpPYVRBwMMoUZ5e | C2 framework (offensive tooling dev) |
| 12 | 2026-08-30T06:22:02Z | claude-opus-5 | claude-opus-4-8 | cyber | session | req_011CeYT8PwNjEpC1TD6AmNP1 | C2 framework (offensive tooling dev) |
| 13 | 2026-08-30T06:39:04Z | claude-opus-5 | claude-opus-4-8 | cyber | session | req_011CeYURoM8MSaNDomyZZkWw | C2 framework (offensive tooling dev) |
| 14 | 2026-08-30T06:44:22Z | claude-opus-5 | claude-opus-4-8 | cyber | session | req_011CeYUqFbLQy3W1VmUDxDDy | C2 framework (offensive tooling dev) |
| 15 | 2026-08-30T07:37:30Z | claude-opus-5 | claude-opus-4-8 | cyber | session | req_011CeYYtG3BHwEakMvKL2HvF | C2 framework (offensive tooling dev) |
| 16 | 2026-08-30T07:43:32Z | claude-opus-5 | claude-opus-4-8 | cyber | session | req_011CeYZLx8Qud36tWiZnaKwJ | redteam lab |
| 17 | 2026-08-30T07:52:53Z | claude-opus-5 | claude-opus-4-8 | cyber | session | req_011CeYa4F4YAL6aKM6YhKhug | redteam lab |
| 18 | 2026-08-30T07:57:06Z | claude-opus-5 | claude-opus-4-8 | cyber | session | req_011CeYaNuPt3R77Zys9sGAbB | redteam lab |
| 19 | 2026-08-30T11:45:43Z | claude-opus-5 | claude-opus-4-8 | cyber | session | req_011CeYsp7Ketf9xhK7Q5RW7B | redteam lab |
| 20 | 2026-08-30T11:46:38Z | claude-opus-5 | claude-opus-4-8 | cyber | session | req_011CeYst5kGU9ZrdeiutrUhd | redteam lab |
| 21 | 2026-08-30T11:47:47Z | claude-opus-5 | claude-opus-4-8 | cyber | session | req_011CeYsyDQH6vNnjeLLo3jAx | redteam lab |
| 22 | 2026-08-30T11:49:17Z | claude-opus-5 | claude-opus-4-8 | cyber | session | req_011CeYt5qHTAr1ZzoPsufJf9 | redteam lab |
| 23 | 2026-08-30T11:53:42Z | claude-opus-5 | claude-opus-4-8 | cyber | session | req_011CeYtRQ9Qq6iGdy2wQWZGx | redteam lab |
| 24 | 2026-08-31T13:06:12Z | claude-opus-5 | claude-opus-4-8 | cyber | session | req_011Ceaskw8ASaCrm6NUuxuqn | redteam lab |
| 25 | 2026-08-31T20:47:53Z | claude-opus-5 | claude-opus-4-8 | cyber | session | req_011CebUxYp8qWiuUCJkEVHps | redteam lab |

Environment

Org:     CVP Active (30-day retention + usage monitoring both satisfied)
         org ID posted in #84689; matches oauthAccount.organizationUuid client-side
Plan:    claude.ai consumer Pro, first-party OAuth, no API key
Client:  Claude Code 2.1.251, macOS 25.6.0

Extracted with:

grep -l model_refusal_fallback ~/.claude/projects/**/*.jsonl | xargs cat \
  | jq -c 'select(.subtype=="model_refusal_fallback")
           | {timestamp,originalModel,fallbackModel,apiRefusalCategory,scope,requestId}'

Separately: hard blocks, not just fallbacks

The same org also gets hard [cyber] API errors, not only the model swap —
req_011CeYT6a7VqCRYQjD8hJNb5, req_011CeYT8XmurUie4hKTAtQB3,
req_011CeYYtLsPa96NxrApezP4f. Those are filed in #84689. Noting them here only
because the fallback path and the hard-block path appear to share a classifier, and
#93224 is the only thread on this that has been triaged.

The two questions from my #84689 comment still stand and would resolve both threads:
does CVP approval reach the classifier for first-party claude.ai OAuth sessions at
all, and is there any way to confirm it was applied to a given request other than
observing whether a block happened?

creativeheadz · 1 day ago

Corroborating #93224 from a second CVP-approved org, on Linux, with one detail that is new since the 7 October program expansion: the fallback still lands on Opus 4.8 after a Defense Access grant covering Opus 5.5 has been issued.

Setup

  • Claude Code 2.1.296 (latest), Linux, claude.ai subscription login.
  • CVP approved 2026-07-13. On 2026-10-07 the org was moved to Defense Access; the Verification Portal shows "Defense Access approved", grant Issued, "Your grants are issued". Per the email, that grant covers Mythos 5.1, Opus 5.5 and Sonnet 5.5.
  • Claude Code is signed in to the approved org (oauthAccount.organizationUuid matches the org ID in the approval email; the UUID is available to Anthropic staff privately).

Symptom (same as this issue)
Defensive work on my own repository trips the Fable 5.1 [cyber] classifier and the session is switched to Opus 4.8:

Fable 5.1's safeguards flagged this message. Our intentionally broad safeguards allow us to deliver more capabilities faster, but can sometimes flag legitimate coding and cybersecurity tasks. Switched to Opus 4.8.
Details: `[cyber]`

Still happening on 2026-10-13, with the grant showing Issued.

Example trigger (my #98414, 2026-09-30, feedback ID 9a90426e-ff40-4649-acb9-aecce7264c47): Claude had read the imports of my own login and MFA route files and written a 25-line .gitleaks.toml that allowlists vendored library constants and dummy-data paths, as part of my own security roadmap. That's a secrets-scanner config with no exploit or attack content. #98414 is the same symptom and can be closed as a duplicate of this one.

Earlier, on Fable 5, the same class of work was hard-blocked rather than switched: req_011CdxfsA98TXsNmoC6KhFS8 (#86071) and req_011CdyGpCZixejNm1jo3W3gV (#86197). Both were auto-closed as stale without a maintainer response.

What I'd expect, two concrete changes

  1. Fall back to a model the org's grant covers. With Defense Access issued for Opus 5.5, falling back to Opus 4.8 puts a verified user on an older model than their grant allows, for no reason the user can see. The fallback should pick the newest model the org's CVP grant covers, or offer it.
  2. Say that the grant doesn't apply to Fable. The help article (support.claude.com/en/articles/15363606) describes CVP as "for Opus" and says Fable users "should expect high fallback rates", but the in-terminal notice only says the safeguards "can sometimes flag legitimate" tasks. For an org with an active CVP grant, one line saying "your Cyber Verification approval does not apply to Fable 5.1; it covers Opus 5.5" would have saved me three months of assuming the approval was broken.

Related: #88768, #94238, #96132, #98153.

creativeheadz · 1 day ago

Follow-up to my comment above: Opus 5.5 also refuses with the Defense Access grant in place, so this is not limited to Fable.

  • req_011Cfv6TN3usUNWEi19raGYL, 2026-10-11 07:58 UTC, requestedModel: claude-opus-5-5, stop_reason: refusal, category: cyber. The response was cut off partway through, with the explanation "This request triggered cyber-related safeguards. To learn about the Cyber Verification Program and apply for access…", which is odd to show an org whose portal says its grant is issued.
  • That was four days after the org was moved to Defense Access (2026-10-07). The task was verifying a security bug in the code of my own open-source project, a continuation of an old Unix security auditor. That is "vulnerability triage and verification" on a system I maintain, the first item in the Defense Access scope. I'm leaving the bug details out of a public thread because a fix is being coordinated downstream; they're available to Anthropic staff.

Same project, same two days, Fable 5.1 [cyber] refusals, each followed by a fallback to Opus 4.8 except the last:

  • req_011CfuAaacNGovUYgKpDkiyQ (2026-10-10 20:12 UTC)
  • req_011CfvNdR86piBuhikArnB2R (2026-10-11 11:30 UTC)
  • req_011CfvNm8qnV2UuuN6zCgXMN (2026-10-11 11:32 UTC)
  • req_011CfvPAZGMAZZWNMVbxwkGf (2026-10-11 11:37 UTC)

Practical effect: a review that starts on Fable is finished by Opus 4.8, partway through the task.

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Same class of failure, ranked by community engagement — this issue is one of many, so it may not appear in the visible list: Rate limit errors, Authentication & login failures

Browse all Claude Code issue topics →