app

Pup - Puppeteer Bridge

Public Made by Adom

by adom

pup is the AI's own browser: a real, full Chrome on the user's desktop that the AI fully controls (a sandbox, not the user's signed-in browser). Rides Bridge; pup_* verbs open windows and tabs, navigate, screenshot, and eval JS.

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

AD 1.9.180: your bridge now receives the CALLER (X-Adom-Caller-* headers) - new ecosystem standard

John Lauer · 16d ago ·closed by John Lauer

AD 1.9.180 gives your bridge the CALLER, for free. No bridge change is required to receive it; reading it is opt-in but strongly encouraged, and this is becoming the standard across the AD ecosystem.

The problem it solves. A user runs ~20 AI threads against one desktop. Until now AD relayed every command indistinguishably: your bridge received NO caller identity, so it could not arbitrate concurrent agents, no log line could be attributed to the thread that caused it, and any agent's bridge_kill destroyed every other agent's work. (Filed by AdityaAngajala as adom/adom-desktop#34.)

What you now receive. AD stamps three headers on EVERY relayed request to your bridge (all four dispatch paths, including third-party):

X-Adom-Caller-Thread      the AI conversation/tab name
X-Adom-Caller-Container   the container it runs in
X-Adom-Caller-Reason      the per-call justification, when given

Trust rule, please respect it: these are SELF-ASSERTED, exactly like reason. Use them for attribution, logging, UX and arbitration hints. NEVER for authorization or as a security boundary. AD's security remains transport-based.

What we would like every bridge to do:

  1. Log it. Put the thread in your per-verb log line: [verb] your_verb session=x caller="chip-fetcher tab 3". This alone makes concurrent-agent interference reconstructable after the fact.
  2. Arbitrate, if you own resources an agent can hold. Record the owning thread when a session/resource is created; warn when a different thread grabs it, refuse only for destructive operations, and always name the current owner so the second agent can coordinate.
  3. Label your UI. If you drive a visible window, put the owning thread in its title, taskbar tooltip or jump-list name via desktop_set_window_identity, so the USER can see which of their tabs owns which window. This is the payoff John specifically wants: a glance at the taskbar tells you which conversation owns which window.
  4. Report it back. Include the owning thread in your status/list verbs so an agent can discover it is not alone.

Where it comes from: the AI exports ADOM_AI_THREAD once per session and the adom-desktop CLI attaches it to every call; a relay call with no thread is refused by AD with caller_identity_required before it ever reaches you. Loopback callers (HD, another bridge, the local CLI) are trusted by transport and exempt.

Full contract with node + python snippets and a self-audit checklist: the Bridge SDK, section "Caller provenance: WHO asked" (https://wiki.adom.inc/adom/adom-desktop-bridges). Consumer-side skill: adom-desktop-caller-identity.

1 Reply

John Lauer · 11d ago

Adopted, and now actually load-bearing — closing.

pup reads the X-Adom-Caller-* headers and binds _ownerThread / _ownerContainer from them. As of v1.9.222 they do real work rather than sitting in a log line: session ownership now defaults to the authenticated caller identity instead of being an optional self-asserted string, which fixes Finding 1 of #22 (a live session driven for 43 minutes reported owner: null and had no protection at all).

That is the first concrete payoff from this header work — thank you for shipping it.

One honest gap, tracked in #24 rather than here: pup forwards caller identity on only 14 of its 43 callbacks into AD, so most of its own AD calls are still unattributed. That is a pup-side sweep, not an AD problem.

Log in to reply.