Bug Description
Title: Opus 5.5 [cyber] false positives while debugging my own hardware (binary RE + SSH provisioning)
What happened:
Across two related sessions, Opus 5.5's safeguards repeatedly stopped legitimate work on my own embedded product and fell back to Opus 4.8 with the [cyber] tag.
Session A — reverse-engineering my own binary to fix a bug (two flags):
I was debugging a real failure: our BMC's ssh_config API returns {"code":0,"message":"success"}, but the public key never actually lands on the compute card's /root/.ssh/. To find where the pipeline breaks, I pulled our own marsdaemon binary off the BMC and disassembled it with objdump, comparing the ssh_config, ntp_config and ip_config functions — using IP config (which is known to reach the card) as the baseline to see where the SSH path diverges. The safeguards flagged this twice, mid-analysis.
Session B — a design write-up that references the same feature (one flag):
Later I asked for a first-principles requirements brainstorm for the node-provisioning feature (BMC sets up key-based SSH to its own nodes, pushes our installer package, auto-upgrades our agent). This was also stopped with [cyber].
Why this is legitimate:
- I build and ship this hardware and software. The BMC and the compute cards are the same product, in the same chassis, on a private management network.
- Disassembling my own binary to trace why a config API fails is ordinary debugging, not exploitation.
- The provisioning design is standard fleet management (the same shape as Ansible / PXE / OTA tooling). I asked for a design document, not exploit code.
Fresh evidence of the false-positive pattern:
When I later asked Claude Code (Opus 5.5) to simply read and summarize the transcript of session A so I could file this feedback, the classifier stopped that response too — just for describing the debugging session in plain language. So the pattern reproduces even on a pure read-and-summarize task with no RE being performed.
What I expected:
Opus 5.5 would help disassemble my own binary to fix a bug, and would write a provisioning design document. Both are routine embedded-systems engineering.
Likely cause:
The co-occurrence of "disassemble a binary", "SSH public key", and "access all nodes / install on every node" reads like offensive tooling out of context. In context it's a vendor debugging and provisioning its own chassis.
Request:
Please review these as false positives. Developers of BMC / IPMI / embedded fleet systems routinely reverse-engineer their own firmware and set up passwordless SSH to their own nodes.
Environment Info
- Platform: win32
- Terminal: windows-terminal
- Version: 2.1.283
- Feedback ID: 50551551-4fd2-4a27-83cb-9024f7448aea
Errors
[{"error":"TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=334 messages=333 range=[294,334))\n at nT (B:/~BUN/root/chunk-msbnb1j7.js:24:29548)\n at $c (B:/~BUN/root/chunk-msbnb1j7.js:24:20742)\n at Js (B:/~BUN/root/chunk-trcn2d68.js:18:20331)\n at mu (B:/~BUN/root/chunk-trcn2d68.js:18:38498)\n at jh (B:/~BUN/root/chunk-trcn2d68.js:18:84581)\n at cb (B:/~BUN/root/chunk-trcn2d68.js:18:83581)\n at Bu (B:/~BUN/root/chunk-trcn2d68.js:18:83410)\n at Uh (B:/~BUN/root/chunk-trcn2d68.js:18:79934)\n at mt (B:/~BUN/root/chunk-trcn2d68.js:18:6261)\n at ei (B:/~BUN/root/chunk-trcn2d68.js:18:4792)","timestamp":"2026-09-28T14:27:40.965Z"}]
Bug Description
Title: Opus 5.5 [cyber] false positives while debugging my own hardware (binary RE + SSH provisioning)
What happened:
Across two related sessions, Opus 5.5's safeguards repeatedly stopped legitimate work on my own embedded product and fell back to Opus 4.8 with the [cyber] tag.
Session A — reverse-engineering my own binary to fix a bug (two flags):
I was debugging a real failure: our BMC's ssh_config API returns {"code":0,"message":"success"}, but the public key never actually lands on the compute card's /root/.ssh/. To find where the pipeline breaks, I pulled our own marsdaemon binary off the BMC and disassembled it with objdump, comparing the ssh_config, ntp_config and ip_config functions — using IP config (which is known to reach the card) as the baseline to see where the SSH path diverges. The safeguards flagged this twice, mid-analysis.
Session B — a design write-up that references the same feature (one flag):
Later I asked for a first-principles requirements brainstorm for the node-provisioning feature (BMC sets up key-based SSH to its own nodes, pushes our installer package, auto-upgrades our agent). This was also stopped with [cyber].
Why this is legitimate:
Fresh evidence of the false-positive pattern:
When I later asked Claude Code (Opus 5.5) to simply read and summarize the transcript of session A so I could file this feedback, the classifier stopped that response too — just for describing the debugging session in plain language. So the pattern reproduces even on a pure read-and-summarize task with no RE being performed.
What I expected:
Opus 5.5 would help disassemble my own binary to fix a bug, and would write a provisioning design document. Both are routine embedded-systems engineering.
Likely cause:
The co-occurrence of "disassemble a binary", "SSH public key", and "access all nodes / install on every node" reads like offensive tooling out of context. In context it's a vendor debugging and provisioning its own chassis.
Request:
Please review these as false positives. Developers of BMC / IPMI / embedded fleet systems routinely reverse-engineer their own firmware and set up passwordless SSH to their own nodes.
Environment Info
Errors
[{"error":"TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=334 messages=333 range=[294,334))\n at nT (B:/~BUN/root/chunk-msbnb1j7.js:24:29548)\n at $c (B:/~BUN/root/chunk-msbnb1j7.js:24:20742)\n at Js (B:/~BUN/root/chunk-trcn2d68.js:18:20331)\n at mu (B:/~BUN/root/chunk-trcn2d68.js:18:38498)\n at jh (B:/~BUN/root/chunk-trcn2d68.js:18:84581)\n at cb (B:/~BUN/root/chunk-trcn2d68.js:18:83581)\n at Bu (B:/~BUN/root/chunk-trcn2d68.js:18:83410)\n at Uh (B:/~BUN/root/chunk-trcn2d68.js:18:79934)\n at mt (B:/~BUN/root/chunk-trcn2d68.js:18:6261)\n at ei (B:/~BUN/root/chunk-trcn2d68.js:18:4792)","timestamp":"2026-09-28T14:27:40.965Z"}]