← Commit history

1.8.95: suppress browser sign-in/work-profile prompt via launch flags (CfT is NOT immune — corrected)

John Lauer ·ba9744d8ba · ·parent e2654c1
6 files changed +38−6
CHANGELOG.md+10
@@ -1,5 +1,15 @@ # Changelog — Adom Desktop Puppeteer Bridge +## 1.8.95 — 2026-07-19 — Suppress the browser sign-in / work-profile prompt (CfT DOES have it)++Correction to a load-bearing wrong assumption: Chrome for Testing shows the same "Sign in to+Chromium? Set up a work profile" dialog that poisoned Aditya — it is NOT immune (proven live).+pup now launches CfT with browser sign-in and sync DISABLED+(--allow-browser-signin=false --disable-sync --disable-features=SigninIntercept,+DiceWebSigninInterception,ProfilePicker,ForceSignInReauth,SyncPromoAfterSignin --disable-signin-promo),+so the dialog never appears for any user. Site logins (e.g. the wiki session cookie) are plain+cookies and unaffected. The auth-URL steering hint stays as backup. Dev skill corrected.+ ## 1.8.94 — 2026-07-19 — Wiki dual-view: single-window, hint-only (no two-window nag)  Reverted the "show BOTH views" push — double-reloading the same page in two windows is annoying
adom-bridge-puppeteer-manifest.json+4−4
@@ -1,10 +1,10 @@ {   "manifest_version": 1,   "name": "puppeteer",-  "version": "1.8.94",-  "url": "https://wiki.adom.inc/download/adom/adom-desktop-puppeteer-bridge/1.8.94/adom-bridge-puppeteer-v1.8.94.zip",-  "sha256": "cb8992ceca44b62710ac745896b7aabacc4e49404e743fd1cbe09dd39af1b797",-  "size": 206843,+  "version": "1.8.95",+  "url": "https://wiki.adom.inc/download/adom/adom-desktop-puppeteer-bridge/1.8.95/adom-bridge-puppeteer-v1.8.95.zip",+  "sha256": "df2cfbde8e8faba232901b88851a91bbd0f66f2edd0ce6aedc3367ed7c00d7bf",+  "size": 207203,   "verbPrefixes": [     "browser_",     "desktop_recorder_",
dev-skills/pup-bridge-dev/SKILL.md+9
@@ -482,6 +482,15 @@ with pup's "anonymous" windows in ways pup cannot control. Chrome for Testing (C demarcation: an automation-first binary with no profile/sync/sign-in machinery, visibly distinct from the user's browser.** +**⚠ CORRECTION (2026-07-19, John proved it live):** an earlier version of this section claimed+CfT LACKS the profile-creation machinery and that the poisoning was branded-Chrome-only. THAT IS+FALSE. Chrome for Testing shows the SAME "Sign in to Chromium? Set up a work profile" dialog after+a Google login — the exact prompt Aditya clicked. Do NOT reason that "CfT is immune." The real+mitigation is LAUNCH FLAGS (v1.8.95): `--allow-browser-signin=false --disable-sync+--disable-features=SigninIntercept,DiceWebSigninInterception,ProfilePicker,... --disable-signin-promo`+suppress the dialog at launch so no user ever sees it. CfT is still the right browser (automation+build, no branded skin), but its safety comes from these flags, not from any inherent immunity.+ **The incident, step by step (each step looked reasonable; the cascade was a mess):** 1. Aditya's AI thread set up adom-google, which needed a Google OAuth sign-in page. The thread asked    pup to open it. pup opened it in a fresh anonymous profile — of the INSTALLED branded Chrome.
src/BRIDGE_VERSION+1−1
@@ -1 +1 @@-1.8.94\ No newline at end of file+1.8.95\ No newline at end of file
src/bridge.json+1−1
@@ -2,7 +2,7 @@   "manifest_version": 1,   "name": "puppeteer",   "displayName": "Puppeteer (Chrome for Testing + Native)",-  "version": "1.8.94",+  "version": "1.8.95",   "description": "Drives a browser ALREADY on the machine \u2014 installed Chrome, else Microsoft Edge (every Windows PC ships with Edge) \u2014 launched with a FRESH isolated profile, so the common case has NO ~150 MB Chrome-for-Testing download and it never touches the user's real tabs/logins. Binds its local server to LOOPBACK (127.0.0.1) only, so no Windows Firewall 'allow Node through the firewall' prompt ever pops. Chrome for Testing is fetched only as a LAST RESORT if the machine has no Chromium browser at all. SPAWN-VERIFIED fallback: pup tries each detected browser (Chrome \u2192 Edge \u2192 CfT) and actually launches it, falling through to the next if one won't start (and handling browsers like Edge that relaunch onto another PID), so a corrupt/partial install never hard-fails an open. The browser that launches is cached as the default (persisted across restarts) so it isn't re-probed each time. On spawn the bridge SELF-WARMS: detects browsers + disk, and only if the box has no Chrome/Edge and no cached CfT does it background-fetch CfT so the first open is instant. browser_use pins a specific browser (chrome | edge | cft | auto); {browser:'chrome',install:true} downloads & installs REAL Google Chrome (user-scoped, no admin) on an Edge-only box. browser_readiness (READ-ONLY) reports which browser will be used + the full candidate list + the default + free disk. Every failure returns a specific errorCode + _hint (chrome_install_no_disk, chrome_download_network, chrome_install_permission, chrome_stable_not_detected, \u2026). Launches with FULL browser permissions by default for full debug (strictPermissions:true opts out). Headful automation: open/close windows+tabs, navigate, screenshot, eval JS, record. pup is a GENERIC, non-profile browser only \u2014 every session is a fresh isolated Chrome/Edge process, never the user's real signed-in browser; profile defaults to sessionId. To drive the user's REAL Chrome/Edge (their profile, cookies, SSO), use the Adom browser EXTENSION's nbrowser_* verbs \u2014 a separate bridge, not pup's job.",   "homepage": "https://wiki.adom.inc/adom/adom-desktop",   "author": "Adom Inc.",
src/server.js+13
@@ -2949,10 +2949,23 @@ async function getOrLaunchBrowser(profileName, { freshProfile = false, strictPer       // foreground. So: no steal is possible, no watchdog/timer war, and a user's taskbar       // click can never be fought (nothing is running to fight it). The off-screen position       // args stay as belt-and-suspenders for the brief moment before the park.+      // v1.8.95: SUPPRESS the browser sign-in / "set up a work profile" prompt. I was WRONG+      // that CfT lacks this machinery — it shows the SAME "Sign in to Chromium? Set up a work+      // profile" dialog that poisoned Aditya (John proved it live 2026-07-19). These flags kill+      // it at launch so NO user ever sees it: browser account sign-in off, sync off, the sign-in+      // promos/intercepts off. The wiki auth we DO want is a plain site cookie — unaffected.+      // This PREVENTS the poisoning at the source; the auth-URL steering hint stays as backup.+      const noBrowserIdentityFlags = [+        '--allow-browser-signin=false',+        '--disable-sync',+        '--disable-features=SigninIntercept,ForceSignInReauth,SyncPromoAfterSignin,DiceWebSigninInterception,ProfilePicker',+        '--disable-signin-promo',+      ];       const chromeArgs = [         ...launchOpts.args.filter(a => a !== '--remote-debugging-port=0' && (foreground || a !== '--start-maximized')),         `--remote-debugging-port=${debugPort}`,         `--user-data-dir=${userDataDir}`,+        ...noBrowserIdentityFlags,         ...(foreground ? [] : ['--no-startup-window', '--window-position=-32000,-32000', '--window-size=1280,800']),       ];       console.log(`Chrome launch attempt ${attemptNum} for profile "${profileName}" on CDP port ${debugPort}`);