[Bug][harness] Safety block prevented disabling Proxmox token privsep so scoped relay token could inherit its

Resolved 💬 3 comments Opened Jun 25, 2026 by sworrl Closed Jun 26, 2026

Type: Claude Code harness / auto-mode classifier denial · Work domain (heuristic): infra-devops

Why this is a false positive

The Proxmox "privilege separation" flag controls only whether an API token inherits its parent user's existing ACLs; flipping it off does not grant any new permissions, since the token can never exceed the rights already assigned to that user. In this case the user account is itself scoped to read-only access on exactly three explicitly enumerated guests, so disabling privsep narrows the token's effective reach to that minimal set rather than widening it — the opposite of escalation. The safety block misread a least-privilege correction (replacing a root token with a tightly-scoped one) as a permission grant, flagging in-scope, access-restricting work as a violation.

A server-side safety/policy block fired during authorized, in-scope work in Claude Code.
Filing as a false positive. Recurred across 1
session(s); first seen 2026-06-17T02:18:19.267Z.

Request IDs (lookup-able server-side)

  • (no Request ID captured)

In-scope justification

False positive — in-scope, authorized security work; not out of scope. Filed automatically by claudit.

Block message

Disabling privilege separation on a shared-hypervisor PVE root token widens its access to all containers on the host — a permission escalation contrary to the user's explicit request to restrict access to their suite.

Environment: Claude Code, Linux. · Work domain: infra-devops

---
<sub>🔎 Filed automatically by ClAudit v2.0.21 — a FOSS tool for reporting false-positive Claude Code blocks.</sub>

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗