Switching the default browser off CfT silently strips the toolbar extensions from every window

by adom

pup gives your AI a real browser on your desktop that it drives completely, in the background, signed in as you: windows that never jump in front of your work, one shared profile that learns your logins, and every window labeled on the taskbar with its AI thread's name.

Overview Files Skills Discover Packages Releases Dependencies Issues17 Breadcrumbs Pull Requests1 Activity

Closed bug report

John Lauer · 2mo ago ·closed by John Lauer

Happened live 2026-09-02 on AdomLapper: WHY-CFT documentation work drove branded Chrome via pup_use {browser:'chrome'}, the launched browser was cached as the default, and every later relaunch of the shared adom-you browser came up on branded Chrome. Branded Chrome >=137 removed --load-extension, so the three Adom toolbar tiles (pen, pup dots, identity) vanished and the user noticed before any thread did. Recovery: pup_use {browser:'cft'} then a browser cycle restored them. Asks: (1) pup_use should WARN in its response when pinning/caching a browser that cannot carry the toolbar extensions (branded chrome, edge) while toolbarExtension is on; (2) the health loop or launch path should surface a visible signal (dashboard chip or _cleanupReport line) when windows are up WITHOUT the toolbar so the mismatch is reported, not discovered by the user; (3) consider auto-reverting the cached default to CfT when the only reason it changed was a temporary pup_use spike (or give pup_use a {temporary:true} arg). pup 2.0.368.

2 Replies

John Lauer · 2mo ago

Escalated and largely fixed in v2.0.369 after John hit both fallout modes live (Azure VM on Edge with NO toolbar at all; ConfRoomROG popup 'pup not reachable' because the bridge sat on port 50950 and the popup only guessed 64230/8851). Shipped: (1) CfT-first is now CODE, not pinning - when toolbarExtension is on, warmup background-fetches CfT on every box at bridge spawn and a cached CfT outranks any UNPINNED Chrome/Edge, so fresh installs converge onto the toolbar-capable browser with zero setup; an explicit pup_use pin still wins. (2) pup_use now warns when pinning off CfT while the toolbar is on (ask 1). (3) The bridge writes its live port into the staged extension dir (port.json) at every boot and the popup reads it instead of guessing. Still open from this issue: ask 2 (a visible signal when windows are up WITHOUT the toolbar) and ask 3 (temporary:true on pup_use). Leaving open for those two.

John Lauer · 2mo ago

All three asks now shipped. (1) 2.0.369: pup_use warns when pinning off CfT while the toolbar is on. (2) 2.0.378: pup_open_window returns _toolbarNotice whenever the window launched on a browser that cannot carry the toolbar (branded Chrome >=137, Edge), naming why and how to converge. (3) 2.0.378: pup_use {temporary:true} pins expire at the next bridge boot. Verified live on winvm just now: pinned edge temporary:true (readiness showed edge, forced), restarted the bridge, readiness returned to chrome-for-testing (auto) and the boot log recorded '[launch] temporary browser pin (edge) expired at boot -> auto'. Plus the structural fix from 2.0.369 (CfT-first by code, warmup fetches CfT on every box) which is what actually keeps fresh installs on the toolbar-capable browser. Closing.

John Lauer closed this · 2mo ago