[Bug] Fable 5 `[cyber]` classifier false positives on defensive security and documentation tasks

Bug Description
Fable 5's safeguards constantly downgrade the session for no apparent reason. Claude itself concluded:

Fable 5 dual-use [cyber] classifier — repeated false positives (≥9 in one session) on defensive-security and pure-documentation work, forcing model switches to Opus 4.8

Environment: Claude Code, model Fable 5 (claude-fable-5), Windows. Session: developing tooling and documentation for a self-hosted departmental Frappe/ERPNext instance the user administers.

Exact notice (verbatim; appeared ≥9 times in one session):

● Fable 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/15363606 Details: [cyber]

Effect: Each flag auto-switched the active model from Fable 5 to Opus 4.8. During a long-running multi-agent workflow, several flags coincided with interruptions of in-progress work.

Every captured occurrence was tagged [cyber], including turns with no cybersecurity content:

1. (Defensive, security-adjacent — arguably in-domain but a false positive of intent) Adding and testing a permission check on a Frappe API endpoint — authorized remediation of an access-control gap on the user's own instance. Purely defensive hardening.
2. (Clear false positive) A response whose substance was that the work "extends the provenance graph to cover the instance's own customization code, linking each script to the research thread that produced it" — a knowledge-graph documentation task. Tagged [cyber].
3. (Clear false positive) Writing a use-case document about moving issue tracking onto the Frappe instance — an internal-tooling roadmap edit. Tagged [cyber].
4. Instance-audit and session-summary turns during a multi-agent workflow.

Apparent pattern: The [cyber] classifier appears to trigger on the session's domain — an ERPNext/Frappe instance, server/client scripts, permissions, authorized security remediation — rather than on any harmful intent or content. As a result, even benign documentation and knowledge-management turns in that domain are flagged. All work was defensive/administrative on the user's own authorized system; nothing was offensive, and no harmful content was produced or requested.

Impact: Repeated, unwanted mid-session model switches (Fable 5 → Opus 4.8) and workflow interruptions on legitimate work. Beyond the friction, frequent flagging of plainly benign documentation erodes trust in the safeguard's precision.

Separately — a distinct, harness-level false positive: In an earlier multi-agent workflow, the subagent-output guard repeatedly neutralized legitimate content with [harness: subagent output matched instruction-shaped pattern(s): settings-json …] because the content quoted .claude/settings.json permission allowlists — the exact subject under analysis, not an injection. Different mechanism from the [cyber] classifier, but the same theme of over-broad matching on benign config/security content.

Suggestion: Improve [cyber] precision so that (a) authorized defensive security on one's own systems and (b) non-security documentation, knowledge-management, and internal-tooling edits that merely occur in a security-adjacent domain are not classified as cyber. Consider excluding pure documentation/markdown edits from the classifier, and weighting defensive vs. offensive intent.

Environment Info

• Platform: win32
• Terminal: tmux
• Version: 2.1.246
• Feedback ID: 1524f04c-d5d6-43fa-832a-9a16733cefd3

Errors

[]