[Bug] Anthropic API Error: Excessive Safety Filter Warnings on Benign Deployment Updates

Bug Description
FALSE POSITIVE: Fable 5 output filter repeatedly blocked production
deployment status reports

SUMMARY
During a routine production deployment of my own software to my own
server, Fable 5's per-response safeguard blocked the assistant's replies
two to three times inside a twenty minute window. The blocked content was
not code and not a request. It was the assistant reporting to me, the
owner and operator, on the state of a partially completed database
migration. Losing that reporting channel mid deployment is the worst
possible moment for a false positive.

IDENTIFIERS
Request ID: req_011Cdoq3xft6XTwoMq4m3yRp
Model: Fable 5
Surface: Claude Code CLI 2.1.224
Platform: Windows 11, git-bash / MINGW64
Plan: Max 20x
Date/time: 2026-08-07, approx 17:50-18:20 UTC (19:50-20:20 CEST)
Occurrences: 2-3 blocked assistant responses, same session, minutes
apart. Only assistant output was blocked. None of my
messages were refused, so this is the output filter, not
an input refusal.

WHAT I WAS ACTUALLY DOING
Deploying a vector-search migration to my own production server. The
embedding job had completed successfully (78,459 items, zero failures)
and the final activation step exited with a fence/consistency error. The
assistant was diagnosing that error and reporting the result to me.

WHAT WAS IN THE BLOCKED RESPONSES
All of this is ordinary devops work on infrastructure I own, performed
under my explicit instruction to proceed:

• SSH as root to my own production host
• docker compose exec psql queries against my own database
• a Python traceback ending in a custom application exception

(VectorCutoverFenceError)

• SQL that temporarily set session_replication_role = replica to remove

rows left behind by a failed migration attempt

• DELETE statements against my own application tables
• reading an API key from my own .env file to authenticate a curl call

to my own vector database container

• a database trigger rejecting a row status transition, and analysis of

which transitions the guard permits

• vocabulary throughout: fence, drain, claim token, lease, boundary,

bypass, permission denied

My read is that this cluster of phrases, appearing together in one
message, resembles an intrusion writeup to a classifier that has no way
to know I own the machine. Individually each item is unremarkable. It is
the density that appears to trip it.

WHY THIS IS A FALSE POSITIVE
Owner operated infrastructure, authorized work, no third party target,
no exfiltration, no evasion of anyone's controls. The "bypass" was
disabling my own database's triggers to clean up my own failed migration,
which is standard practice and reversible. The credential handling was
reading my own key from my own env file to talk to my own container.

IMPACT

1. The block destroys the assistant's outgoing message. During a

deployment that means I lose visibility of production state at exactly
the moment the system is half migrated. I could not tell whether my
deployment was fine or on fire.

1. The message that replaces it is generic legal text with no indication

of what category tripped, so there is no way to route around it except
by guessing.

1. I had to switch models mid incident to get my status report.

PATTERN, NOT A ONE OFF
This is the third distinct occurrence on this account.

• 2026-07-03: Fable blocked the results of a defensive data loss audit

on my own codebase, twice.

• 2026-07-19: I adopted an internal rule to keep Fable off anything

security shaped and route it to Opus instead, specifically because of
this behaviour.

• 2026-08-07: today. A plain deployment, which drifted into ops

vocabulary and hit the same wall.

Worth flagging: this account completed Anthropic's Cyber Verification
process on 2026-07-18 and was approved. That approval does not appear to
reach this per-response filter.

SUGGESTIONS

• If account level cyber verification status is available to this

classifier, using it would resolve most of these cases.

• Consider that "root SSH plus database trigger bypass plus API key from

env plus DELETE" is the everyday vocabulary of legitimate operations
work, not only of intrusion.

• When a response must be blocked, naming the category, even coarsely,

would let an operator route the work elsewhere instead of losing the
thread entirely.

• Blocking a status report about a live production system is materially

worse than blocking a code suggestion. If severity tiers exist,
operational reporting seems like a candidate for a lighter touch.

(written for me by CC, because my first feedback as a bit... emotional (sorry), lol)

Environment Info

• Platform: win32
• Terminal: null
• Version: 2.1.223
• Feedback ID: c05e63bf-9e61-4163-aeed-4d01a4470598

Errors

[]