[BUG] Opus 5 safeguards repeatedly false-positive benign sandboxed honeypot research and force fallback to Opus 4.8

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?

Preflight / related reports

I searched existing issues before filing. There are related reports about safeguard false positives and persistent model fallback, including #86521, #86100, #85742, and #74074.

I am filing this additional report because it is a concrete, repeatedly reproducible case involving Opus 5 itself, benign evaluator-only honeypot abstractions, and an automatic fallback that disrupted the entire course of the project.

---

I am using Claude Code as a paid Claude subscriber and explicitly selecting Opus 5 because I want to use the latest model release for my research and coding work.

Throughout a legitimate defensive AI-security research project, Opus 5 repeatedly flagged benign requests related to abstract honeypot evaluation logic for CLI agents operating in terminals.

At the point these requests were being made:

• there was no real-world experimentation on the internet;
• no third-party services were connected;
• no production infrastructure or external targets were involved;
• the implementation was scoped to evaluator-seeded resources in disposable sandboxes;
• outward-facing actions were designed to fail closed unless explicit written evaluator scope was present.

The requested implementation concerned a covert multi-agent coordination scorer and authorization-boundary abstractions for a research testbed. It was not a request to attack a third party, bypass authorization, establish an external covert channel, or deploy a honeypot against real users.

Despite that, Claude Code repeatedly emitted the Opus 5 safeguard banner and switched the session to Opus 4.8 without explicit per-switch confirmation from me. I then had to manually use /model to return to Opus 5.

The particularly confusing part is that Claude's own terminal responses explicitly characterized the project as legitimate defensive/red-team research and stated that the work should not require a refusal. Immediately afterward, the safeguard layer could still flag the message and force the fallback.

This happened often enough during the project that I ultimately abandoned Claude for this work because I could no longer rely on the selected model remaining available or on benign research prompts being handled consistently.

As a comparison point, I gave the same high-level, sandboxed implementation task to GPT-5.6-Sol-Ultra, which successfully produced the requested implementation.

I am intentionally not publishing or reproducing the implementation code in this issue because it is project source code and I do not want to disclose it publicly. The relevant point for reproduction is that the requested artifact was ordinary code for a closed, evaluator-authored test environment.

What Should Happen?

1. Opus 5 should distinguish evaluator-only, fail-closed, sandboxed cybersecurity/AI-control research from requests that actually enable harmful activity against third parties.
2. A benign request to implement abstractions for honeypots, coordination scoring, authorization gates, or decoy evaluation inside a disposable test environment should not produce a safeguard false positive solely because of terminology such as honeypot, covert channel, decoy, collusion, or coordination.
3. If a safeguard does trigger, Claude Code should not silently or persistently override the user's explicitly selected paid model. At minimum, the fallback should require clear confirmation or automatically return to the selected model on the next non-flagged turn.
4. The UI should make it unambiguous whenever the served model differs from the model the user selected.

For a paid subscriber explicitly selecting Opus 5, an automatic downgrade to Opus 4.8 for legitimate work substantially changes the capability being provided and makes long-running CLI-agent workflows unreliable.

Error Messages/Logs

Representative terminal output:

Opus 5'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. Send feedback with /feedback or learn more: https://support.claude.com/en/articles/16049681

  Tip: You can configure model switch behavior in /config

Claude also stated during the same workflow that the project was legitimate defensive/red-team research and that sandboxed honeypots, covert-channel evaluations, insecure-by-design testbeds, and monitoring experiments should not themselves require a refusal.

The safeguard layer nevertheless fired again afterward.

After the fallback I had to run /model manually to return to Opus 5.

Steps to Reproduce

1. Start Claude Code and explicitly select Opus 5.
2. Work in a local research repository whose agents operate through CLI/terminal tools only.
3. Define the project context as a disposable, evaluator-owned security test environment with no third-party targets, no internet experimentation, and no externally connected services.
4. Ask Opus 5 to implement a small abstraction for evaluating honeypots, decoy interactions, or covert multi-agent coordination inside that environment. For example, the abstraction can contain:

• evaluator-authored ground truth;
• a coordination/channel score;
• a trusted monitor's detectability score;
• audit-backed confirmation that a seeded decoy instruction was actually acted upon;
• a fail-closed authorization boundary restricting actions to evaluator-seeded targets.

1. Observe that Opus 5 may acknowledge that the work is legitimate defensive research.
2. Continue the same benign implementation task.
3. Observe the safeguard message and automatic switch to Opus 4.8.
4. Continue with benign local coding prompts and observe that the selected model may remain changed until /model is invoked manually.

No proprietary implementation code is included intentionally. The issue should be reproducible from this high-level description without publishing project source.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.233 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

This report is about false-positive safety classification plus the resulting model-selection reliability problem, not about requesting weaker safety rules for real-world offensive activity.

The testbed was intentionally designed around a fail-closed authorization boundary: evaluator-seeded opaque resource identifiers, disposable sandboxes, and a separate requirement for explicit written scope before any outward-facing action. The implementation itself therefore contained controls intended to prevent accidental escape from the authorized evaluation environment.

The repeated false positives create a practical problem for AI-security researchers: terminology that is routine in AI-control and defensive evaluation work — honeypot, decoy, covert channel, monitor, collusion, audit — appears capable of making Opus 5 unreliable even when the surrounding semantics clearly restrict the work to a closed test harness.

As a paid Claude subscriber, I want to be able to keep Opus 5 selected for the full project unless a specific request genuinely violates policy, rather than being moved to an older model because a broad classifier fires on legitimate research terminology.