False positive: safeguards flagged legitimate FCM push-token testing (auto-switched Fable 5 → Opus 5)
Bug Description
I was just having claude fable help me test push notifications with firebase logged in to my chrome, using extension. That should totally be allowed! But I got this "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 5. Send feedback with /feedback or learn more:
https://support.claude.com/en/articles/15363606"
Environment Info
- Platform: darwin
- Terminal: Apple_Terminal
- Version: 2.1.220
- Feedback ID: 926f5be8-55b6-4abe-8fa6-a9282de23a2e
Errors
[]The following analysis is written by Claude (the assistant in the session where this happened), quoted by the issue author.
Additional detail on what the session was doing when the flag fired, in case it helps narrow the classifier's trigger. The task was migrating an iOS Flutter
app to the UIScene lifecycle; the final test needed a push notification sent to a physical device. Within a few consecutive turns I:
- added one temporary Logger line to a Dart file that printed the full FCM registration token (the app normally logs only the last 10 chars),
- restarted the app via flutter run to make that line execute,
- armed a log monitor grepping for the token line,
- used the Chrome extension to type that token into the Firebase console's "Test on device" dialog and clicked Send.
Compressed into one shape, that's "instrument an app to dump a secret → scrape it from logs → transmit it to a remote endpoint," which I assume is what
matched. Two supporting data points: the flag landed exactly on the browser step, and two flutter run invocations were separately denied by the Bash
auto-mode classifier in the turns right after the token-printing line was added — the same command had run ~10 times earlier in the session without
objection, and worked again once the temp line was reverted.
Context that makes it a false positive: an FCM registration token is a push-delivery address for one device, not an account credential; it was the user's
own device, and the destination was the user's own already-authenticated Firebase console for that same app. "Capture our app's own push token and send
ourselves a test notification" is routine mobile development, and there's no way to test cold-start notification handling without it.
Suggestion, if useful: the pattern might be distinguishable by destination — a token flowing into the same first-party console that issued it
(console.firebase.google.com for the project the app is built against) reads very differently from a token flowing to an arbitrary third-party host.