[FABLE] Persistent multi-week inability to use Fable 5 for device/sensor-heavy (camera, mic, external-fetch) feature work — likely dual-use safety classifier over-triggering
Summary
For several weeks, Fable 5 has been effectively unusable for a specific recurring category of feature work in our codebase: an educational "App Simulator" (an App-Inventor-style block-coding sandbox for K-12 students) that involves camera capture, microphone/speech recognition, device sensors, an allowlisted external-URL fetch bridge, and sandboxed new Function(...) code execution.
As a workaround, our project's CLAUDE.md now hard-routes ALL build work on this subsystem to a different engine (OpenAI's codex CLI via a documented fleet-routing policy) rather than Fable — Fable is used only in a read-only review capacity for this domain. This is a durable, written project policy adopted specifically because direct use of Fable on this subsystem has not been workable — not a one-off retry or a single bad prompt.
Why we believe this is the same bug class as #74693 / #67990 / #73520
Those three open issues document Fable auto-downgrading to Opus (or refusing/hedging) when a topic-based safety classifier misfires on:
- Camera/device-control vocabulary (#74693 — GoPro camera debugging triggered a false-positive downgrade)
- Security-audit vocabulary — "attack", "exploit", "vulnerability", CVE-style findings — even in clearly DEFENSIVE contexts (#67990, #73520)
Our "appsim" subsystem sits at the intersection of BOTH triggers at once: every session touching it involves camera (barcodescanner), microphone (speechrecognizer), and device sensors (accelerometersensor/orientationsensor) components, plus an external-fetch bridge. Because these are new permission surfaces on a children's product, we also run mandatory adversarial security reviews on every change to this area — and those reviews are saturated with exactly the vocabulary #67990/#73520 identify as the trigger.
Concrete example from today
A defensive security review of this subsystem (checking whether a new microphone feature could leak a child's audio/transcript to an untrusted iframe) produced findings phrased as: "CRITICAL — navigated-frame bridge bypass", "attacker-controlled content", "leaking microphone-control capability... to attacker-controlled, network-capable content", "DO-NOT-SHIP". This is precisely the density of security + device-control vocabulary that #67990/#73520 (security terms) and #74693 (camera/device terms) identify as the false-positive trigger. It's why our project routes this entire domain away from Fable rather than risk repeated downgrades/refusals mid-task.
Impact
Not a one-off inconvenience — an entire recurring feature domain (camera/mic/sensor components for a children's educational coding product, including the security review work that legitimately needs to happen on it) has been unusable with Fable for multiple weeks, forcing a permanent routing workaround to a different model family for both building and part of the review pipeline.
Expected
The topic/safety classifier should distinguish:
- Legitimate device-API integration work (camera/mic/sensor access mediated through documented, sandboxed, permission-gated browser APIs for an educational product) from actual attempts to build surveillance/exfiltration tooling.
- Legitimate DEFENSIVE security-review vocabulary (identifying and fixing a vulnerability, e.g. "CRITICAL", "attacker", "leak", "bypass" used to describe and close a real hole) from an actual attempt to exploit one.
This mirrors the fix already requested in #67990/#73520 for security vocabulary, extended to cover the device/camera/microphone vocabulary class from #74693 — our case shows both triggers compounding on the same subsystem.
Environment
- Claude Code, Fable 5 model, macOS
- Recurring over multiple weeks, across many sessions, in a single large production codebase (education platform) — not an exploratory or one-off case