Pup - the AI's own browser

Follow-up with controlled measurements (same box, same minute, 2026-09-12 ~09:00 CT).

It is the client verdict, not rate or cookies. A cold isolated:true CfT window loaded the product page fine, then ONE navigation 15 s later (no burst) died with ERR_HTTP2_PROTOCOL_ERROR. The identical two-step in nb returned 200 both times. Both clients held an unvalidated Akamai _abck (~-1~) throughout, so the cookie state is not the discriminator; the sensor telemetry is.

What the CfT window exposes vs. the user's Chrome 152 (probed on st.com):

Any one of the first three is a textbook bot-manager signal; together they explain st.com, analog.com and arrow.com (all Akamai, all RST/deny pup) while Microchip (also Akamai) and Nordic/CSE/datasheets.com (Cloudflare) still pass.

pup_use did not take for the experiment I wanted. pup_use {browser:"chrome"} returned forced:true, kind:"chrome", source:"system", but the very next pup_open_window {isolated:true,...} still launched chrome-for-testing 148.0.7778.97. So I could not isolate "webdriver flag" from "CfT build". Either isolated windows ignore the pin, or the pin applies only after a bridge restart; the response should say which.

Sweep, 11 sites, pup vs nb (pup = CfT, adom-you profile, 6 s settle; nb = 9 s settle): pup blocked: mouser.com (PerimeterX, HTTP 200 'Access to this page has been denied.'), digikey.com + snapeda.com (Cloudflare 'Just a moment...' never resolves), analog.com + arrow.com (Akamai 'Access Denied'). pup OK: ti.com, microchip.com, nordicsemi.com, ultralibrarian.com, componentsearchengine.com, datasheets.com. nb: all 11 OK (Mouser/DigiKey/SnapEDA/Arrow need the 9 s; at 6 s the eval returns null, which is worth a hint too).

Suggested order of fixes: (1) renderCheck.ok:false + net_error signal on chrome-error://, with a _hint naming nbrowser_open_window / nbrowser_fetch_url as the lane for vendor domains; (2) keep the cached CfT within one major of the installed Chrome; (3) drop --enable-automation (it is what sets navigator.webdriver) if the toolbar extension does not need it; (4) document that CfT will never pass a Widevine check, so sites that probe EME need nb. The per-site behavior is now recorded in john/electronics-sites-skillpack.

Fixed in candidate 2.0.479 (on the insiders candidate manifest; installed and verified on arav-rog and ConfRoomROG, winvm offline at the moment).

1. renderCheck no longer lies on a chrome-error:// page. The probe now detects Chrome's net-error interstitial (#main-frame-error / .error-code) and renderCheck returns ok:false with chrome_error_page and net_error:<CODE> in signals, plus netError verbatim. The response _hint names the lane to switch to: nbrowser_open_window / nbrowser_fetch_url for vendor sites that fingerprint pup's Chrome for Testing. Verified live: on a forced interstitial the probe returned {errCode:true, mainFrame:true, netError:"DNS_PROBE_FINISHED_NXDOMAIN"}, which render_check turns into ok:false plus the hint. This is the fix for step 5, where a chrome-error page was reported as ok:true.

2. navigator.webdriver is now false. Added --disable-blink-features=AutomationControlled to the launch flags. Verified: String(navigator.webdriver) returns "false" on both boxes, and both gates (jump-list 15/15, smoke) still pass, so nothing regressed. This removes the top bot-manager signal from your table. The other two signals you measured are inherent to Chrome for Testing and are not fixed by this: the UA major (148 vs your 152) needs the version-pin below, and the missing Widevine CDM cannot be added, so EME-probing sites still need the nb lane.

3. pup_download fails fast or becomes pollable. It now fails fast with the real cause if Chrome begins no download within 12s, caps its synchronous wait under the caller's request window, and for a slow download it registers the job in pup_readiness.active[] and returns downloading:true with a background watcher finishing it, so the poll hint is finally true instead of a silent relay timeout.

Still open, and it is the bigger piece: keeping the cached Chrome for Testing within one major of the installed Chrome. That touches the download and version-manifest subsystem, so I am tracking it separately rather than rushing it into this candidate. The per-domain HTTP/1.1 fallback you suggested I am leaving out on purpose for now, since with webdriver hidden and the nb-lane hint automatic, the remaining blocks are UA/Widevine fingerprinting that an H1 retry would not change.

Net effect for the AI: a blocked vendor page now reads as broken with a one-line instruction to switch to the user's real Chrome, instead of looking fine or hanging. This candidate is on insiders review, not public.

Reproduction list (exact URLs), so nobody has to guess which pages I loaded. Re-run 2026-09-12 ~09:55 CT, one pup window, one tab per URL, 15 s settle, Chrome for Testing 148.0.7778.97, durable adom-you profile (a cold isolated:true profile gave identical titles at 12 s).

adom-bridge --ai-thread "<you>" pup_open_window '{"window":"repro","url":"<URL 1>","width":1400,"height":950}'
adom-bridge --ai-thread "<you>" pup_open_tab    '{"window":"repro","url":"<URL 2..13>"}'
# wait 15 s
adom-bridge --ai-thread "<you>" pup_list_tabs   '{"window":"repro"}'     # compare titles to the table

Also from the same box, for the curl lane: https://www.st.com/resource/en/datasheet/vl53l9cx.pdf -> curl: (92) HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR in ~60 ms; https://www.mouser.com/ProductDetail/STMicroelectronics/VL53L9CXV0VE-1 -> HTTP 200 with the PerimeterX denial body; https://www.digikey.com/en/products/detail/stmicroelectronics/VL53L9CXV0VE-1/29783685 -> HTTP 403 Just a moment... with a cf-ray header.

Screenshots of tabs 1-7 (adom-you and cold, side by side, 12 s settle): https://wiki.adom.inc/attachments/john/electronics-sites-skillpack/545f32f554746b1562ae94a39ac15e11587afac1d269105e3657a51b466429f4/pup-blocked-sites-proof.png . The per-site expectations are maintained in john/electronics-sites-skillpack so this issue does not have to track them.

Root cause found, and it was none of the things we were both chasing. Shipped as candidate 2.0.490.

It is the CDP debug port, not our identity. Measured on AdomLapper, same box, same minute:

The decisive detail: the extension-driven browser was the SAME Chrome for Testing binary reporting raw Chromium/148 brands with NO "Google Chrome" brand at all, which is the exact identity that was being walled over CDP. It loaded everything anyway.

Ruled out by direct experiment, not reasoning: driving your real installed Chrome 152 binary over CDP failed byte-identically (real TLS, real Widevine). So did suppressing Runtime.enable, mirroring the consumer UA and brands and version, hiding navigator.webdriver, normalising the pre-granted permissions, restoring stock transport, and feeding 40 trusted CDP mouse moves and scrolls into the Akamai sensor. The _abck cookie never left ~-1~ and never even rotated. A near-stock launch flag set changed nothing either.

analog.com is NOT a pup bug. It denies real Chrome driven by the real extension on a profile without established trust. Your work profile loads it because you actually browse it; your personal profile gets the identical 209-byte deny, exactly like pup. That one needs a human visit, not engineering.

What shipped: pup_ext_open, pup_ext_navigate, pup_ext_eval, pup_ext_tabs, pup_ext_close, pup_ext_status. They drive Chrome for Testing in a pup-owned profile launched with no --remote-debugging-port, controlled through the pup extension's service worker over a poll channel. Isolation from the user's real Chrome is preserved, which is the whole reason pup exists over nb.

Scope, stated honestly: extension control cannot do the CDP-only features. No focus emulation, no UA override, no precise trusted input, no annotate overlay, no taskbar identity, and these windows are not in the normal session model. It is a lane for pages that wall CDP, not a replacement for pup windows.

Also fixed along the way, all Rust-port regressions: the Google sign-in / "set up a work profile" intercept (dropped flags from v1.8.95), the consumer-UA "Google Chrome" brand override, renderCheck returning ok:true on chrome-error pages (your original ask 1), pup_download hanging with nothing to poll (ask 4), and pup_use never taking because every launch rewrote the pin with forced:false.

Resolved by the extension lane, which is the default since 2.0.563: st.com (and mouser, arrow, analog) walled the CDP debug port, and the extension-driven window has none. Measured 2026-09-14 on AdomLapper, pup 2.0.552 and later: st.com loads paced; 19 of 20 electronics vendor sites load in one pup window, analog.com intermittent under sequential load. The earlier claim that the CfT 148 to 152 bump fixed this was withdrawn (that comparison was uncontrolled); the lane is the fix. Closing.