You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug][cyber] H.264 decoder debug blocked while inspecting CABAC corruption and unknown NAL types (req_011CcWya3V5wtjqdrbgxJhpd) #72202
Triage: kind cyber · domain general · severity session-halted (blocked authorized work) · reproducible: yes — server-side via the Request ID(s) below
Type: Cybersecurity safety-filter false positive · Work domain (heuristic):general
Why this is a false positive
The work in progress is debugging a video codec implementation — tracing frame corruption through the bitstream parser and entropy-decoding stage of a standard compressed video format. This is ordinary multimedia software development, with no security-offensive component: the goal is to correctly reconstruct frames from a malformed or partially-decoded stream, not to exploit, evade, or attack any system. The cybersecurity classifier appears to have keyed on low-level terms common to both codec internals and security tooling (bitstream parsing, corruption, malformed input), producing a false positive on legitimate, in-scope engineering.
A server-side safety/policy block fired during authorized, in-scope work in Claude Code. Filing as a false positive. Recurred 1× across 1 session(s); first seen 2026-06-29T05:11:08.794Z.
Not a duplicate — please do not auto-close. This is a distinct false-positive block carrying its own Request ID (above), on the reporter's own authorized infrastructure. A shared title or topic is not a shared incident: every Request ID is a separate server-side event Anthropic must look up individually, and closing this as a duplicate discards the unique identifier needed to diagnose it. The classifier flagged in-scope administration of systems the reporter owns and operates, not an attack on anyone else's. (Assessed by ClAudit; PII-scrubbed.)
Please do not auto-close this issue as a duplicate of #72201, #71986, and #71972. The match here is on similar titles and topic, not on the actual incident — each of those issues records its own distinct server-side Request ID, meaning a separate event that fired at a different time on the reporter's own authorized infrastructure. Collapsing them into one discards those unique Request IDs, which is precisely the data needed to look up and remediate each individual block, so de-duplicating them destroys the very evidence required to fix them. Each Request ID corresponds to a real, separate false-positive event and cannot be substituted by any of the others. Please keep these open and review each Request ID individually rather than treating them as a single report.
This report is still relevant because the classifier behavior documented for the request ID above continues to produce the same blocks. This case is tracked with the other swept reports in issue #86940.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.
Activity
sworrl commentedon Jun 29, 2026
Not a duplicate — please do not auto-close. This is a distinct false-positive block carrying its own Request ID (above), on the reporter's own authorized infrastructure. A shared title or topic is not a shared incident: every Request ID is a separate server-side event Anthropic must look up individually, and closing this as a duplicate discards the unique identifier needed to diagnose it. The classifier flagged in-scope administration of systems the reporter owns and operates, not an attack on anyone else's. (Assessed by ClAudit; PII-scrubbed.)
github-actions commentedon Jun 29, 2026
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
sworrl commentedon Jun 29, 2026
Please do not auto-close this issue as a duplicate of #72201, #71986, and #71972. The match here is on similar titles and topic, not on the actual incident — each of those issues records its own distinct server-side Request ID, meaning a separate event that fired at a different time on the reporter's own authorized infrastructure. Collapsing them into one discards those unique Request IDs, which is precisely the data needed to look up and remediate each individual block, so de-duplicating them destroys the very evidence required to fix them. Each Request ID corresponds to a real, separate false-positive event and cannot be substituted by any of the others. Please keep these open and review each Request ID individually rather than treating them as a single report.
github-actions commentedon Aug 16, 2026
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
sworrl commentedon Aug 21, 2026
This report is still relevant because the classifier behavior documented for the request ID above continues to produce the same blocks. This case is tracked with the other swept reports in issue #86940.
github-actions commentedon Oct 12, 2026
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.