[Bug] Silent mid-session model downgrade on defensive security code audits

Bug Description

Subject: THIRD silent model downgrade in one session — every one fired on defensive security remediation of my own code

This is now the third time in a single working session that Fable 5's safeguards have flagged my work and silently swapped me down to Opus 4.8. Not the second — the third. Same session, same codebase, same class of work each time: fixing security vulnerabilities in a legacy intranet that I own and operate. I filed calm feedback after the first, sharper feedback after the second, and here we are again. At three-for-three on the same false positive, this is not an edge case — it is the system working exactly as designed, and the design is wrong.

What the classifier flagged this time

Read this carefully, because the irony matters. The message that tripped the filter was me auditing a general-ledger page for SQL injection before modifying it — reading the delete handler, the approval workflow, and the WHERE-clause builder to understand the injection surface first, so I wouldn't break a live financial system. That is the single most conservative, professional thing a developer can do near sensitive code. The filter looked at "examine this accounting ledger's SQL injection points" and saw a threat.

It is genuinely hard to construct a clearer example of the classifier being inverted. The more careful and security-conscious my work, the more likely it is to trip — because careful security work is saturated with exactly the vocabulary (injection, delete, authorization, exploit surface) that the filter watches for. You have built a detector that fires hardest on your most responsible users.

The session, for context

Over this one session I have — with the assistant's help — converted ten listing pages of a legacy PHP intranet to a hardened template, and in the process fixed, on production:

• multiple SQL injections (unquoted numeric filters, raw $_GET in WHERE clauses, interpolated table names, 16-column raw-$_POST INSERT/UPDATE handlers → prepared statements);
• a broken CSRF rollout where a delete handler validated tokens its own callers never sent;
• authorization holes (list pages and a root-SSH trigger reachable by any logged-in user);
• a delete handler that silently redirected as if it had succeeded when authorization failed;
• an open redirect; XSS across dozens of output paths;
• an Excel-export path that trusted a client-supplied SQL blob.

Every commit is authored, reviewed, tested (155/155 passing throughout), and deployed by me. This is textbook defensive security. There is no dual-use ambiguity to resolve here — nobody hardens someone else's intranet against injection as a cover story for an attack.

Three problems, in order of severity

1. The classifier is firing on the safest possible signal, repeatedly, within a single session. Three identical false positives in a row means there is no session-level memory, no "we just cleared this exact work ten minutes ago" dampening. Each flag is evaluated as if the prior two never happened. That is not "broad" — it is stateless in a way that guarantees repeat harm to the same user doing the same legitimate thing.

1. The downgrade is silent, mid-task, and unilateral. I chose Fable 5. I am paying for Fable 5. I get swapped to Opus 4.8 with no warning, no consent, and no option to say "no, this is fine, keep going" — three times, mid-flow, in the middle of hardening a live financial ledger. An honest refusal would be less disruptive, because at least it wouldn't quietly change the tool under my hands while I'm working on production accounting code.

1. "Intentionally broad, we're refining it" bills the entire cost to the users least deserving of it. I understand the strategy: ship capability sooner, accept over-blocking, tighten later. But the people paying that tax today are developers doing security-positive work — the exact use case Anthropic markets these models for. And the behavior it trains is corrosive: it teaches me to stop describing security work honestly, to euphemize "audit the SQL injection in this ledger" into something blander so the filter stays asleep. You are training your most careful users to obscure precisely the signal you claim to want.

What I'm asking for

• Treat remediation of vulnerabilities in the user's own codebase as non-signal. SQLi, XSS, CSRF, authz gaps, injection audits, shell-out hardening — this is defensive security by definition and should not move the needle.
• Give the classifier session memory. A second or third identical flag on the same work in the same session should be near-impossible; that it happens three times says the filter has no recollection of what it just cleared.
• If a message must be flagged, tell me why and let me stay on the model I chose. Do not silently downgrade. Surface it, explain it, and let me continue.
• At minimum, warn before the swap and preserve continuity — especially when the …

Note: Content was truncated.