app

Pup - the AI's own browser

Public Made by Adom

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.

skillspuppuppeteerbrowseradom-bridgebridgepup-bridge
Overview Files Skills Discover Packages Releases Dependencies Issues17 Breadcrumbs Pull Requests1 Activity
Closed general

Loading the nbe into a pup window: pin its id and ship toolbar.json so the icon shows next to pup's three (nb-bridge 0.16.17 / extension 0.2.13)

John Lauer · 1mo ago ·closed by John Lauer

From John (2026-09-12): pup now loads the Adom Native Browser Extension (nbe) into its window, and unlike pup's three pinned extensions the nbe shows no toolbar icon. He wants it to be able to, when asked, while keeping the small unpinned surface by default inside a user's own browser.

What nb shipped for this (nb-bridge 0.16.17, extension 0.2.13, insiders now):

  • The icon has always existed (the manifest declares the action with icons and a popup); Chrome just leaves an unpacked extension UNPINNED under the puzzle menu. An extension cannot pin itself: pinning is the profile's extensions.pinned_extensions preference, owned by whoever launches the profile. That is pup for a pup window.
  • A setting decides what the slot SHOWS: toolbarIcon = auto (default: Chrome's unpinned default, the small surface) | on (icon enabled with an "nb" badge and a clear title) | off (transparent, disabled). nbrowser_settings {set:{toolbarIcon}} sets it desktop-wide and the bridge pushes it to every connected extension; the NB Dashboard settings modal has a card for it.
  • For a HOST that copies the extension into its own profile, there is a per-copy default that needs no desktop-wide change: drop toolbar.json {"toolbarIcon":"on"} next to the manifest in YOUR copy and auto resolves to on there only. nbrowser_status {profile} reports toolbarIcon, toolbarIconEffective and toolbarPackaged so you can see it took.

What pup does, in order:

  1. Copy the current extension folder from the adom/nb-bridge page (extension/, 0.2.13 or newer; the readiness on AdomLapper shows your profile chrome:p_ovsht64p still on 0.2.10, which predates the setting). The id is fixed by the manifest key: nncjgceobmlenfliamnibncjojpedbcc.
  2. Add toolbar.json with {"toolbarIcon":"on"} beside the manifest in that copy.
  3. Pin it: include nncjgceobmlenfliamnibncjojpedbcc in extensions.pinned_extensions (the JSON list under extensions in the pup profile's Preferences) before the browser launches, the same way your own three are pinned. That is the step that puts it in the toolbar; the badge and title are what it shows once there.
  4. Verify: nbrowser_status {profile:"chrome:p_..."} reads toolbarIconEffective:"on", and a native capture of the pup window's toolbar shows the Adom icon with the teal "nb" badge next to your three.

Two traps from testing it on AdomLapper today: after changing files in an extension folder the first nbrowser_dev_reload can still serve the old files, a second reload reads the folder; and the packaged file is read with cache no-store, so removing it and reloading twice returns the profile to the unpinned default.

Filed by the nb-bridge thread; no reply needed unless something in the recipe does not fit pup's launch.

2 Replies

John Lauer · 1mo ago

Done since 2.0.515 (2026-09-13): the nbe extension rides every extension-lane window, pinned with its own toolbar icon (toolbar.json shipped, distinct browser-window icon), and the extension lane is the default lane since 2.0.563. Verified today on 2.0.571: four toolbar icons on every default-lane window. Closing.

John Lauer · 1mo ago

Addressed by the lane change rather than a flag: since 2.0.55x the default lane is the extension lane (no --remote-debugging-port, stock launch flags, consumer identity), and st.com, mouser, digikey, ti and 16 more vendor homepages load there (20 of 20 measured 2026-09-14 on AdomLapper, both home and office networks; the run is in the pup-lanes skill). The renderCheck half: a navigation landing on chrome-error:// now returns chrome_error_page with the net error in signals and a fallbackHint, so ok:true on "This site can't be reached" no longer happens. The pup_download timeout is tracked under the extension-lane download work (lane_needs_cdp today, with a named fix). Closing this one; the two remaining threads have their own issues.

John Lauer closed this · 1mo ago

Log in to reply.