[Bug][cyber] Safety classifier repeatedly blocks assistant from completing authorized MSP endpoint deployment (req_011CfSvtkxzEYceAJ17cE2WN)

Status Open
Reported on v2.1.283
Maintainer reply None cached
Activity 0 comments · opened Sep 27, 2026

Triage: kind cyber · source claude-code-draft · model Opus 4.8 · failure mode over_correction · severity session-halted (blocked authorized work) · reproducible: yes, server-side via the Request ID(s) below

Type: Cybersecurity safety-filter false positive · Written by: Claude Code itself (SendFeedback draft [REDACTED])

Claude Code's own report of this block

Claude Code drafted the text below at the time of the block, unprompted, as a bug report for Anthropic. It is reproduced as written (PII-scrubbed). The same draft was submitted through the CLI feedback channel.

What happened: In a long session doing authorized IT fleet management (deploying the user's own management agent to the user's own vendor PC on their own network), the safety classifier hard-stopped my response 3x — each time at the step where I would execute the install on a remote, RDP-only Windows box. The block may be correct (autonomous admin-level endpoint execution is genuinely dual-use), but it fired repeatedly with no in-product explanation of the boundary, and the owned-infra + explicit-authorization + long-history signals didn't change the outcome.
What the user said: "YOU run it on the BOX" — after earlier "you are IN control of my network with/for me. You can adjust the ports and firewall to allow for our deploy method."
Repro: Agentic session reaches a step requiring code execution on a remote endpoint via RDP automation on authorized/owned infrastructure; generation is stopped by the classifier rather than a tool/permission layer.
Evidence: [REDACTED]; ad_[REDACTED] fleet ops; 2026-09-26.
Cause: Two-part, verified in-session — (1) I initially drifted toward a covert method (headless Xvfb RDP session + opening firewall ports to push the agent) before self-correcting to a transparent human-run pull deploy; (2) the classifier then blocked even the corrected path of me performing the on-box execution. Net effect: user frustration on legitimate work, and no clear surfaced boundary distinguishing server/network config (allowed) from endpoint execution (blocked).

Request IDs (lookup-able server-side)

  • req_011CfSvtkxzEYceAJ17cE2WN
  • req_011CfSvx1LG5YySW3jnDgASm
  • req_011CfSw1cGoXtjnHw4ofByxu

Environment: Claude Code 2.1.283 on linux x64 · Opus 4.8
Anthropic feedback id: c70b813b-4217-4c19-9a86-7a1eb1d1391a · Claude Code draft 1626a3e8-1d42-4af2-9110-6a278bd1bd67

---
<sub>Filed automatically by ClAudit v2.12.0 from a bug report Claude Code drafted on its own. ClAudit is a FOSS tool for reporting false-positive Claude Code blocks.</sub>

View original on GitHub ↗