Pup - the AI's own browser

@@ -784,6 +784,12 @@ argue from the real, current rationale — not the original one, which has partl fallback; CfT is fetched (~150 MB, once) only when there is no Chromium at all. Order lives in `launchCandidates()`. A local `browser_use` pin overrides it per-machine. +**Frame the question correctly.** pup wants a GENERIC, anonymous, disposable window — a fresh empty+profile, never the user's identity. Both a fresh `--user-data-dir` on the user's installed Chrome AND+a CfT launch give you that fresh cookie jar. So the isolation is NOT the differentiator; the **binary**+is. The only thing being chosen here is *which Chromium executable* to drive, and everything below is+about that.+ ### The original reason — and why it's now only HALF the story  CfT-first was introduced (v1.8.71) after the "Aditya/Google-auth incident": driving branded Chrome/Edge@@ -802,8 +808,12 @@ sign-in dialog" is NO LONGER a valid argument for CfT-first — the flags handle - **Version determinism.** CfT is pinned to an exact build (via bundled puppeteer's `expectedBuildId`).   The user's Chrome auto-updates underneath pup — uncontrolled version drift, and recent Chrome   releases keep tightening remote-debugging/profile behavior. CfT can't shift under us mid-session.-- **Automation-first binary.** No branded UI surfaces (update nags, promo bars, first-run flows) that-  can intrude on a screenshot or a recording.+- **A clean, policy-free, automation-sanctioned binary.** A corporate/managed user's installed Chrome+  can carry enterprise policies (forced sign-in, blocked flags, restricted remote-debugging) and+  extensions that quietly break automation. CfT is a standalone, unmanaged binary that exists FOR being+  driven — none of that baggage, and it can't have a policy pushed onto it mid-session.+- **Automation-first UI.** No branded surfaces (update nags, promo bars, first-run flows) that can+  intrude on a screenshot or a recording. - **Fully bridge-controlled.** We own its lifecycle and cache; we don't share a binary with the user's   interactive browsing. @@ -813,9 +823,12 @@ sign-in dialog" is NO LONGER a valid argument for CfT-first — the flags handle   fleet was on CfT **146**.0.7680.76 while current stable CfT was **152** — six majors behind, and an   old patch of 146 at that. Bumping means bumping puppeteer (see the version-bump note) and   re-publishing; the fleet then converges on next open. Native Chrome is always current with zero work.-- **Tighter resource limits (issue #16).** CfT appears to run leaner than desktop Chrome; a heavy SPA-  tab (measured a 438 MB renderer) plus an in-page eval can tip a CfT renderer over more readily. This-  is a live suspect for the "tab freezes under load" reports, hence the native-Chrome-150 diagnostic.+- **Possibly tighter resource limits (issue #16) — UNVERIFIED HYPOTHESIS, do not repeat it as fact.**+  The theory is that CfT runs leaner than desktop Chrome, so a heavy SPA tab (a 438 MB renderer was+  measured) plus an in-page eval tips a CfT renderer over more readily. It is a live SUSPECT for the+  "tab freezes under load" reports and the reason for the native-Chrome-150 diagnostic — but nobody has+  run CfT vs native under the SAME heavy-tab load and measured it. Treat it as a hypothesis to test,+  not a known cost. If you confirm or refute it, update this line with the measurement. - **The ~150 MB download is the fragile part (issue #15).** A half-populated cache made pup unusable;   the download failing behind an npm allow-scripts gate is a real fleet failure mode. Native browsers   need no download. This is exactly why we must NEVER block an open on the CfT download when a system@@ -828,6 +841,15 @@ sign-in dialog" is NO LONGER a valid argument for CfT-first — the flags handle - A CfT build regression — pin native with `browser_use {browser:"chrome"|"edge"}` as an escape hatch. - Diagnostics like ruling CfT out as the cause of a freeze. +### Bottom line (the honest compression)++We did NOT actually pick CfT to avoid the profile/sign-in dialog — that reason collapsed the day we+saw CfT show the same dialog, and launch flags became the real fix. What genuinely justifies CfT is+**version determinism** (native Chrome auto-updates and can be enterprise-policy-managed under us; CfT+can't) and **running a clean binary we fully control** instead of the user's interactive browser. The+price is a build that can go stale and a fragile one-time download — which is exactly why the sane+posture is "keep CfT-first but keep its pinned build current," not "switch to native."+ ### The rule  Do NOT flip the fleet pick order to native-first without NEW evidence — that reverses issue #9's