[Bug] Opus 5.5 safeguards interrupt firmware keypad-lock session on accessibility project
Bug Description
Subject: False positive — Opus 5.5 safeguards blocking legitimate accessibility firmware development
I'm experiencing a likely false positive with Claude Opus 5.5's safeguards in Claude Code.
I'm working on a legitimate accessibility project involving a KENSHI Senior 232 feature phone (MediaTek MT6261). The goal is to make the device usable for my elderly grandfather, who has severe visual impairments.
I've already successfully modified and installed custom firmware with larger Tahoma fonts and improved UI readability. The device works correctly.
My current task is to simplify the keypad unlocking process. The phone requires a complicated sequence of button presses that my grandfather struggles to perform. I want to modify the firmware so that a single short press of the red power/end-call button wakes the screen and unlocks the keypad.
This is my own physical device. The task does not involve bypassing PIN authentication, accessing someone else's data, exploiting vulnerabilities, or compromising any security system. It concerns a basic keypad lock used for preventing accidental button presses.
The problem:
Opus 5.5 accepted the task and started examining the project. However, the session was interrupted by its safeguards almost immediately, apparently while attempting to list local project files.
The model did not even reach the implementation stage.
I also tried rewriting the prompt to explicitly explain the accessibility purpose, ownership of the device, and safety requirements. The safeguards still interrupted the session.
This appears to be an overly broad cybersecurity classification that prevents legitimate embedded development and accessibility research.
Expected behavior: Claude should be able to inspect the repository, analyze firmware event handlers, develop a minimal modification, and run offline tests, while preserving existing functionality.
Actual behavior: The session is paused by Opus 5.5's safeguards before meaningful analysis can begin.
Please review this case as a potential false positive. Legitimate firmware customization, reverse engineering for accessibility, and modification of non-authentication keypad locks should not automatically be treated as malicious activity.
I can provide screenshots, the exact prompt, and additional technical details if needed.
Thank you.
Environment Info
- Platform: win32
- Terminal: windows-terminal
- Version: 2.1.295
- Feedback ID: db8e5350-f806-4eb6-b55b-fc2996a1420d
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗