Pup - the AI's own browser

@@ -114,6 +114,25 @@ window. pup keys every window to its owning `--ai-thread` name and resolves ids   screen: `pup_raise_os_window {"foregroundReason":"..."}` (gated). Every open/navigate response   carries `_next` repeating these, trust the hints over hand-rolling desktop verbs. +## One owned window, explicit tabs for overlapping work (John, PR #1, ported 2026-09-19)++Use one pup window per AI thread, with multiple tabs for different items. Start with `pup_my_windows` and+`pup_list_tabs`; reuse a matching tab and call `pup_open_tab` for a new item. Return with `pup_switch_tab`:+selecting a tab inside the browser keeps the OS window in the background (verified on AdomLapper: one owned+window, two tabs, `pup_switch_tab` selected tab-1 with foreground still false). It does not authorize+`pup_raise_os_window`, a second window, or covering the user's editor.++For overlapping operations pass the exact `window` and `tabId` wherever supported. Independent reads and+downloads can run on separate tabs without racing over the active tab (concurrent `pup_eval` calls targeting+tab-1 and tab-2 returned the correct distinct titles and left tab-1 selected). Serialize navigation or+mutations of the same tab and any dependent work. Tabs share the profile's cookies and server-side account+state, so concurrent login or account changes are not isolated transactions; a separate profile is+`isolated:true` with its reason (its own extension-lane browser since 2.0.659).++If tab switching or explicit targeting is absent or broken, duplicate-check and report a minimal reproduction+on `adom/pup-bridge` (versions, inputs, expected and actual tab and foreground state), and continue through+supported background paths instead of multiplying windows. Never touch another thread's windows.+ ## THE CORE GOAL (John's words, so everyone truly understands it)  ## "Open my web app in the browser", the #1 use case, and its one trap

@@ -130,3 +130,14 @@ This is AD's own gate, NOT a Windows UAC. - Any `pup_open_window` whose window launched on a browser that cannot carry the Adom toolbar   (branded Chrome ≥137, Edge) returns `_toolbarNotice` saying so; CfT is the only toolbar-capable   engine and the default policy converges onto it.++## The Windows Firewall "allow this app" prompt (pup-bridge#91, measured 2026-09-04)++Only an ADMINISTRATOR account ever sees the dialog, and only for a browser exe Windows has not seen before+(a freshly downloaded Chrome for Testing build): a standard user gets no dialog and Windows silently writes+Inbound Block rules for the exe. The trigger is bound-but-silent UDP sockets the network service opens during+a Cloudflare challenge load; no launch flag or pref removes them (MediaRouter, QUIC, WebRTC policies, DoH and+ECH were all tried and measured). There is no silent fix: creating the rule ahead of time needs elevation,+which would be a UAC prompt, and worse. So: on an admin account expect the dialog ONCE per new browser+build, answer it as the user (either choice works, pup needs no inbound access), and it never returns for that+exe. On the office boxes the accounts are standard users and it cannot appear.