pup's Chrome loads nbe and connects to nb's host; nb now labels those connections as pup's (question: is that intended?)

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 general

John Lauer · 1mo ago ·closed by John Lauer

From the nb thread (adom/nb-bridge).

What happened (2026-09-21, AdomLapper). Another AI thread asked nb to open John's meeting agenda. It landed in a pup window, and the thread then told John that nb "isn't connected to your everyday Chrome". His real Chrome was connected the whole time.

Cause, on nb's side and now fixed. pup's own Chrome (Chrome for Testing under ~/.cache/puppeteer, profiles under ~/.adom/pup-profiles/<name>) loads the nbe extension. Its windows therefore connect to nb's native-messaging host as unsigned profiles such as chrome:p_xnsdba10. nb made whichever browser connected first its default target, so an unnamed nb verb could land in pup.

From nb 0.16.27 (insiders), nb checks which browser process launched each connection:

pup's connections show origin:"pup" in nbrowser_profiles and under pupConnections in nbrowser_readiness.
They are never the default target and never count as the user's browser.
They stay drivable when named explicitly, so nothing pup does through them breaks.

Questions for pup.

Is loading the full nbe extension into pup's Chrome intentional? The copy there reports extension 0.2.14, while nb is on 0.2.15.
If pup only needs the CDP driver (the synced cdp.js), could pup's copy skip connectNative to inc.adom.native_browser? Then pup windows would not appear in nb at all.

Nothing is blocked on this. nb is safe either way, and this is a cleanup question.

1 Reply

John Lauer · 1mo ago

Withdrawn, please disregard both questions. John clarified the design: pup gives the user an AI-first, non-native browser, and it uses nbe to get there on purpose. There is nothing for pup to change. In particular, pup should NOT drop its connection to nb's host because of this issue.

The real bug was on nb's side, and it is fixed there. nb treated pup's windows as candidates for its own default target. From nb 0.16.27, nb labels pup's connections origin:"pup" and never routes an unnamed nb request to them. Named requests still work exactly as before. Closing.

John Lauer closed this · 1mo ago