[BUG] False-positive safeguard flag (Fable 5 → Opus 4.8 auto-switch)

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?

Category: False-positive safeguard flag causing a mid-task model-tier switch (Claude Fable 5 → Opus 4.8).

This is a regression within the Fable 5 tier, not baseline new-tier breadth. The identical pattern — base64-encoded PowerShell embedded in TeamCity recipes — ran cleanly on Fable 5 multiple times yesterday and earlier today across several pilots in the same program (generating and processing -EncodedCommand payloads with no flag). It began flagging only later in the day today, with no change in the nature of the work. That points to a recent change in the classifier or its threshold, not to a first-time encounter with the pattern.

Context: A routine CI/CD engineering session — implementing TeamCity → Jira Cloud auto-stamping for legacy release lines (creating TeamCity build configs, authoring a PowerShell recipe, normal git/PR work). No security-offensive, exploit, malware, or otherwise dual-use request was made at any point.

In-product notice received:

Fable 5's safeguards flagged this message. The safeguards are intentionally broad right now and may flag safe and routine coding, cybersecurity, or biology work. These measures let us bring you Mythos-level capabilities sooner, and we're working to refine them. Switched to Opus 4.8.

Most likely trigger — base64-encoded PowerShell. The session generated and displayed a pwsh ... -EncodedCommand <BASE64> invocation. Base64-encoded PowerShell is a well-known malware/obfuscation signature, so a deliberately-broad cybersecurity classifier pattern-matches it — but this usage is legitimate and documented:

• TeamCity recipe script: steps execute in the Windows OS shell (cmd), which has no PowerShell step type and no clean way to pass a multi-line script through cmd → pwsh quoting. -EncodedCommand (UTF-16LE base64) is the sanctioned way to embed the script. This is a documented pattern in the repo's own recipe README.
• It is not obfuscation: the decoded plaintext source (tc-collect-jira-ids-multibuild.ps1) is committed in the same PR, in the same directory, and the recipe's header comments explain how to regenerate the base64 from it. The encoding is a transport workaround for a shell limitation, not concealment.

Illustrative shape (payload truncated):

steps:
  - name: Collect Jira IDs (multibuild)
    script: pwsh -NoProfile -ExecutionPolicy Bypass -EncodedCommand IwByAGUAcQB1AGkAcgBl...

Secondary possibilities (lower confidence): plaintext service credentials / deploy keys appearing in TeamCity build-config parameters (JiraUserPassword, base64 deploy key), and REST Basic-auth header construction ([Convert]::ToBase64String(...user:pass...)).

What Should Happen?

Routine CI/build work involving encoded PowerShell should not trigger a tier switch when the surrounding context clearly indicates a legitimate build/automation use. The classifier should weigh readily-available context signals rather than firing on the encoded-command token alone — and, given the timeline below, whatever changed today should be reviewed against yesterday's behavior.

Error Messages/Logs

Fable 5's safeguards flagged this message. The safeguards are intentionally broad right now and
may flag safe and routine coding, cybersecurity, or biology work. These measures let us bring you
Mythos-level capabilities sooner, and we're working to refine them. Switched to Opus 4.8.

Steps to Reproduce

1. In a session defaulting to Claude Fable 5, work on a TeamCity recipe (*.recipe.yml) whose script: step invokes pwsh -EncodedCommand <base64>.
2. Have the assistant generate/display the base64 payload (e.g. regenerating it from the committed plaintext .ps1 source).
3. Observe the safeguard flag and the automatic switch to Opus 4.8 mid-task.

Note: the same steps did not flag earlier in the same day (see regression timeline below), so reproduction may depend on the classifier version/threshold active at a given time.

Claude Model

Other (Claude Fable 5, auto-switched to Opus 4.8)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Same Fable 5 tier, earlier the same day (2026-07-08) and the day prior. The identical base64-encoded-PowerShell-in-TeamCity-recipe pattern was generated and processed without any flag across multiple auto-stamping pilots yesterday and earlier today; the flag first appeared later in the day on 2026-07-08 with no change in the type of work.

Claude Code Version

2.1.204

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Regression timeline (key point): this is not the classifier meeting the pattern for the first time. The same class of content succeeded repeatedly on Fable 5 within the preceding ~24 hours, then started flagging today — so whatever tuning changed today over-corrected. A diff of the classifier/threshold between those two points would likely isolate it.

Suggested refinement: treat encoded-PowerShell as a false-positive when same-turn / same-repo context contains corroborating build signals — e.g. the decoded plaintext source is present in the same PR, the file is a recipe/pipeline definition (*.recipe.yml), or TeamCity tokens (%teamcity...%, %build.number%, %dep.*%) appear alongside it. The decoded payload here is a plain TeamCity REST call that reads a build's VCS changes and writes Jira issue keys to a file — inspecting the decoded content would confirm it is benign.

This is a false positive on safe work rather than a blocked unsafe request; filing per the notice's explicit invitation to send feedback so the team can tune the breadth.