[Bug] False positive on legitimate business automation (web scraping for first-party sales data)

Status Open
Reported on v2.1.220
Maintainer reply None cached
Activity 0 comments · opened Aug 4, 2026

Bug Description

Hello,

I'd like to report a safeguard false positive that interrupted a legitimate engineering session.

Context

I maintain an internal data pipeline that retrieves our own publishing sales data from
roughly 20 retailer/distributor portals where our company holds contracted accounts.
The pipeline uses Playwright to log in with our own credentials, download the reports
our contracts entitle us to, and feed them into GCS/BigQuery for internal reporting.
This is ordinary first-party business automation, performed against accounts we own or
are authorized to use.

What was flagged

The session was working on session-management and logout reliability for one of these
scrapers. The model was downgraded from Fable 5 to Opus 5 mid-task. I believe the
following legitimate terms co-occurred and resembled a prohibited pattern:

  • Reading credentials from environment variables and filling login forms

(e.g. SERVICE_ID / SERVICE_PW, input[type="password"]`)

  • Discussion of a shared account and concurrent login / session conflict, which in

our case refers to an account legitimately shared with a business partner

  • Prior work in the same session on bot-detection friction: setting a realistic

user agent, --disable-blink-features=AutomationControlled, and reasoning about
reCAPTCHA Enterprise scores when running headless

  • Notes about avoiding repeated login attempts to prevent account lockout

Why I think this deserves attention

Our project rules explicitly forbid synthetic DOM manipulation (JS-dispatched clicks,
direct value injection) and require real mouse/keyboard events via Playwright's normal
APIs, precisely so our automation behaves like a human operator and does not stress the
sites we depend on. Ironically, that more conservative approach is what produces the
vocabulary that appears to trigger the classifier: to make headless Chromium behave like
the ordinary browser a human would use, we must discuss browser fingerprinting and
detection scores.

Legitimate uses of browser automation for first-party data retrieval are extremely
common in business settings, and the current sensitivity makes sustained work in this
area difficult. I would be grateful if signals such as consistent first-party framing,
an established multi-hour engineering context, and the absence of any third-party
targeting could be weighted more

Thank you for the continued work t workflow itself has been
genuinely excellent for this project, which is why I am taking the time to report this.

Best regards,

Environment Info

  • Platform: darwin
  • Terminal: ghostty
  • Version: 2.1.220
  • Feedback ID: 07f5e43d-f557-4f58-9b29-cf03cb4617f1

Errors

[]

View original on GitHub ↗