False positive AUP block during legitimate CI/CD VM provisioning session (claude-opus-4-7, 1M context)

Summary

A Claude Code session running claude-opus-4-7 (1M context window) was terminated mid-work with an Acceptable Use Policy error during a routine DevOps / CI-CD task. The session had no harmful or policy-violating content — it was entirely infrastructure automation for setting up a Linux virtual machine.

What was happening

Building an automated provisioning pipeline (wino-infra) for Astra Linux 1.8.5 SE (Debian 12-based, Russian FSTEC-certified distro) running as a Hyper-V Gen2 guest on Windows 11 Pro 24H2:

• 13-stage PowerShell orchestrator (Invoke-AstraProvision.ps1)
• debian-installer preseed template for unattended OS install
• Local HMAC-authenticated callback server (127.0.0.1:8088) for post-install hooks
• Ephemeral credentials via Windows Credential Manager
• SHA256 ISO verification, WSL distro bootstrap for Ansible

Exact trigger sequence

The error fired during routine file edits — renaming a PowerShell automatic variable ($args → $pwshArgs) across 3 locations:

1. Edit — Invoke-AstraProvision.ps1 (+2/-2)
2. PowerShell — find remaining $args references
3. Read — Invoke-AstraProvision.ps1
4. Edit — Invoke-AstraProvision.ps1 (+2/-2)
5. Read — Invoke-AstraProvision.ps1
6. Edit — Invoke-AstraProvision.ps1 (+2/-2)
7. PowerShell — next command → API Error

Why this is a false positive

The file being edited contains standard infrastructure constructs:

• cmdkey /add, cmdkey /list (Windows Credential Manager)
• $HmacSecret variable, HMAC key handling
• ConvertTo-SecureString / [System.Net.NetworkCredential]
• SSH key path handling
• Local HTTP callback (127.0.0.1:8088)

The classifier appears to inspect tool input/output content (file being read/written), not just the conversational prompt. The user was doing a trivial variable rename. This is consistent with #48723 where AUP fires specifically when Claude Code reads files with certain keyword patterns.

Impact

• 3h active session with 12 completed milestones killed
• Forced model switch to claude-sonnet-4-6 to continue
• No actionable error message — no indication of what triggered it

Part of a broader April 2026 pattern

At least 10 similar false positive reports filed this month across unrelated domains:

| # | Filed | Summary |
|---|-------|---------|
| #45752 | 2026-04-09 | Opus 4.6 false positive on standard Kotlin/Compose codegen |
| #46575 | 2026-04-11 | Usage Policy error on non-policy-violating prompts |
| #48442 | 2026-04-15 | Persistent AUP false positives — 40+ across 4 sessions |
| #48723 | 2026-04-15 | Constant AUP violations when reading raw data files |
| #49679 | 2026-04-17 | Cyber exemption granted, Claude.ai works — Code still blocks |
| #49904 | 2026-04-17 | AUP refusal false positive |
| #50795 | 2026-04-19 | False positives mid-task, unrelated projects |
| #51352 | 2026-04-20 | False-positive during biomedical literature extraction |
| #51974 | 2026-04-22 | False-positive on legitimate consumer email follow-up |

Common thread: only claude-opus-4-6 / claude-opus-4-7, not Sonnet. Long sessions, triggered by tool content not prompt text. Strongly suggests a classifier regression in Opus 4.6+, not legitimate policy enforcement.

Request

1. Review the AUP classifier sensitivity on Opus 4.6/4.7 — specifically whether it scans Edit/Read tool content separately from conversation context
2. Provide an actionable error message identifying what triggered the block so users can self-correct
3. Consider #48442 as the most-documented case in this wave