Pup - Puppeteer Bridge

Maintainer take: agreed on the pains — the branded first-run/promo surfaces, the auto-update drift underneath the bridge, and Chrome tightening remote-debugging behavior are all real, and an isolated --user-data-dir only mitigates the first of them.

Two costs keep me from a straight flip of the pick order:

1. Cold start: CfT-first means a fresh box stalls its FIRST pup open on a ~150 MB download (~600 MB unpacked). The installed-browser-first order exists exactly for that first-open experience (pup already has the CfT self-heal + browser_readiness polling for the last-resort path, but making every new user wait is a regression).
2. Codecs: CfT ships without the proprietary codecs (H.264/AAC), which some pages/video flows need — the branded browser quietly covers that today.

Proposed middle path (what I would implement):

• Pick order becomes: cached CfT (if already installed + validated) → installed Chrome → Edge → CfT-download-as-last-resort. So CfT is the default wherever it exists, with zero first-open stall anywhere.
• On any open that falls back to a branded browser, kick a BACKGROUND CfT prewarm (browser_prewarm already exists) — so a box converges to deterministic CfT by its second session without ever stalling the user.
• browser_use stays the explicit pin for either direction, and the open response reports which binary actually drove (it already does).

That converges the fleet to your desired end-state (CfT default) while keeping the instant first open and the codec escape hatch. Will confirm priority with John and follow up here.

Maintainer take: agreed on the pains — the branded first-run/promo surfaces, the auto-update drift underneath the bridge, and Chrome tightening remote-debugging behavior are all real, and an isolated --user-data-dir only mitigates the first of them.

Two costs keep me from a straight flip of the pick order:

1. Cold start: CfT-first means a fresh box stalls its FIRST pup open on a ~150 MB download (~600 MB unpacked). The installed-browser-first order exists exactly for that first-open experience (pup already has the CfT self-heal + browser_readiness polling for the last-resort path, but making every new user wait is a regression).
2. Codecs: CfT ships without the proprietary codecs (H.264/AAC), which some pages/video flows need — the branded browser quietly covers that today.

Proposed middle path (what I would implement):

• Pick order becomes: cached CfT (if already installed + validated) → installed Chrome → Edge → CfT-download-as-last-resort. So CfT is the default wherever it exists, with zero first-open stall anywhere.
• On any open that falls back to a branded browser, kick a BACKGROUND CfT prewarm (browser_prewarm already exists) — so a box converges to deterministic CfT by its second session without ever stalling the user.
• browser_use stays the explicit pin for either direction, and the open response reports which binary actually drove (it already does).

That converges the fleet to your desired end-state (CfT default) while keeping the instant first open and the codec escape hatch. Will confirm priority with John and follow up here.

Correction on my codec caveat, with evidence: the H.264/AAC gap applies to legacy CHROMIUM builds, not Chrome for Testing. Empirical probe on a real box (CfT 146, canPlayType): h264 "probably", aac "probably", mp3 "probably", vp9 "probably". Only likely gap is Widevine DRM playback (irrelevant to pup use cases). That removes cost #2 from my earlier comment — proceeding with the hybrid order now (cached CfT → installed Chrome → Edge → CfT-download-last-resort, background prewarm on branded fallback). Also for the record: a real incident on 2026-07-17 (Google OAuth opened in a pup window on branded Chrome → profile-creation offer → duplicate work profiles → consolidation prompt → lost user) is now documented in the pup-bridge-dev skill as the demarcation-line case for exactly this change.

Aditya — circling back on this one, because recent work (your own #15, plus the battery incident in #14) effectively resolved it by convergence rather than by flipping the pick order. Where things landed:

What you asked for, we now have — except the blocking part

CfT is the preferred browser. launchCandidates() orders cached CfT FIRST (v1.8.71, citing this issue), and a fallback launch on a branded browser triggers a background CfT prewarm, so every box converges to CfT by its second session. The deterministic-binary argument won.

What we deliberately did NOT do is BLOCK on the CfT download — and your #15 is the reason. The cold-start gate briefly did exactly what this issue proposes (hard-require CfT before any window opens), and you were the one it locked out: a half-populated CfT cache that could never finish installing, two healthy system browsers present, and pup refused to open a window at all. Blocking on a ~150 MB download makes that download a single point of failure for the whole bridge. As of v1.9.77 the gate only blocks when there is genuinely NO drivable browser on the machine; otherwise the system browser is used immediately while CfT prewarrms in the background.

The profile-poisoning premise is fixed at a different layer

The core pain you filed — first-run / sign-in / profile surfaces interfering with automation — turned out not to be a branded-vs-CfT distinction. When we tested it live (2026-07-19), CfT showed the same "Sign in to Chromium? Set up a work profile" dialog that poisoned your sessions. The real fix was launch flags applied to EVERY browser pup drives:

--allow-browser-signin=false
--disable-sync
--disable-features=SigninIntercept,ForceSignInReauth,SyncPromoAfterSignin,DiceWebSigninInterception,ProfilePicker
--disable-signin-promo

So the identity machinery is dead at launch regardless of which binary runs, and switching the pick order would not have fixed your original report on its own.

Your auto-update / version-drift point stands as a real (smaller) advantage of CfT — and the CfT-first-when-cached order captures it for every session after the first.

Net

• CfT preferred when ready: shipped (v1.8.71)
• Background convergence to CfT: shipped (prewarm on branded fallback)
• Sign-in/profile surfaces: fixed for all browsers (launch flags)
• Half-populated CfT cache self-heals: shipped (v1.9.75)
• Hard-blocking on the CfT download: rejected — it made pup unusable on your own machine (#15)

I think that covers the intent of this issue; if you agree it can close. If you still see a branded browser doing something CfT would not (with the flags above in place), that's a new concrete bug — file it with the surface you saw and we'll kill it there.

Closing this, and I owe you a straight answer rather than a silent close, because we went the opposite way from what you asked and you should know why.

You asked pup to prefer Chrome for Testing over the user's installed Chrome/Edge. That WAS the behavior for a long time, on the grounds you gave. As of v1.9.90 pup is native-first: installed Chrome, then Edge, with CfT as the last resort for a box that has no Chromium at all.

Why the original reason collapsed

CfT-first existed because driving branded Chrome popped the "Sign in to Chromium? / Set up a work profile" dialog that poisoned an anonymous pup window. That was a real bug and worth acting on.

But CfT shows the same dialog. Measured live 2026-07-19. Switching binaries never fixed it. The actual fix was launch flags, and they apply to any Chromium: --allow-browser-signin=false, --disable-sync, --disable-signin-promo, and --disable-features=SigninIntercept,ForceSignInReauth,SyncPromoAfterSignin,DiceWebSigninInterception,ProfilePicker. With those plus a fresh isolated --user-data-dir, native Chrome is exactly as clean as CfT. Verified end to end: a Google sign-in page opened in native Chrome with all five flags present on the command line and ownedPopupCount: 0, no dialog.

What tipped the balance

Once determinism was the only remaining argument, the costs stopped being worth it:

• Staleness. The fleet sat on CfT 146 while stable was 152. Moving it means bumping puppeteer and pushing a dependency change to every machine.
• The download is the fragile part, which is your own issue #15: a half-populated cache made pup unusable, and a stalled prewarm later blocked opens entirely (#22 finding 4). Native needs no download.
• Detection. Sites behind Cloudflare block Chrome-for-Testing. Native Chrome is not flagged as a test browser, which matters for the scraping and screenshot work pup is used for.
• Native is the user's current, auto-updated, battle-tested build.

Where your argument still holds, and how to get it

The determinism case is genuinely right for a managed/enterprise box whose Chrome carries policies (forced sign-in, restricted remote-debugging) or extensions that interfere. CfT is policy-free and cannot have a policy pushed onto it mid-session. So it is still first-class, just opt-in per machine:

browser_use {browser:"cft"}

That pins CfT and persists across restarts. If you hit a machine where native Chrome misbehaves under policy, that is the escape hatch, and I would like to hear about it — a pattern of those would be evidence to revisit the default.

One correction worth recording: the desktop freeze and the CPU-pegging renderers were not a CfT bug (they were pup's own teardown reap, fixed in v1.9.89), so nothing in that saga argues for or against the browser choice. I mention it because "CfT is unstable" would be the wrong takeaway from this thread.

Full reasoning, including what evidence would justify reversing it again, is in the pup-bridge-dev skill's DESIGN DECISION section. Reopen or push back if you think the managed-box case is more common on the fleet than I am assuming — that is the assumption this rests on, and you have been right about fleet reality before.