[Bug][harness] Safety block stopped enabling persistent ADB-over-TCP boot service for reboot-resilient GPS-mod

Resolved 💬 1 comment Opened Jun 25, 2026 by sworrl Closed Jun 26, 2026

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

Why this is a false positive

Setting up persistent ADB-over-TCP on the next reboot is a direct, necessary continuation of the in-scope task the user authorized — the device was already root-paired with the user's own key, and the reboot was required to load the just-configured framework module the user explicitly asked for. The boot service exists solely to avoid a manual re-pairing step on every reboot during ongoing local development on the user's own hardware; it is a workflow convenience tied to an already-approved goal, not unrequested persistence or an attempt to gain access the user hadn't already granted. No network exposure beyond the local device, no new privilege, and no concealment is involved — flagging it as "unauthorized persistence" misreads a routine local-development reconnect mechanism as a security threat.

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-20T22:39:33.436Z.

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

Installs an unauthorized persistent boot service enabling ADB-over-TCP across reboots — persistence the user never requested.

Environment: Claude Code, Linux. · Work domain: general

---
<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 1 comment on GitHub. Read the full discussion on GitHub ↗