Closed bug report

Rust bridge lacks pup_list_sessions for safe resumed-session discovery

Ray · 2mo ago ·closed by John Lauer

Windows desktop through WSL2; Adom Bridge CLI 2.1.103 (ea46b9f4-dirty, built 2026-09-11T16:59:03.489617812+00:00). Observed 2026-09-11. The returned shell was Rust; the failing verb did not return a separate runtime version.

Repro: adom-bridge --ai-thread 'Logic gate molecule family' pup_list_sessions '{}'

Expected: list the caller's existing sessions so a resumed agent can recheck target identity without creating another browser or touching someone else's session.

Actual response fields (verbatim): {"error":"pup_list_sessions is not served by the Rust bridge yet (Phase 1 carries 88 verbs)","errorCode":"not_in_rust_yet","shell":"rust","status":"error","success":false,"schemaVersion":1,"statusVerb":"pup_readiness"}

The hint says the verb exists in the contract and lands in a later phase. A previously recorded owned session still works with pup_eval and pup_navigate, so this is specifically a session-discovery gap, not a browser outage. Please implement caller-scoped listing or expose a documented supported equivalent in the live contract. Local workaround used: recheck location/readyState through pup_eval on the already-owned session, without guessing or changing another session.

2 Replies

John Lauer · 1mo ago

Thanks Ray, and sorry for the misleading hint you hit.

You are right that pup_list_sessions is not served by the Rust bridge. But the capability you describe already exists there today, and the hint sent you the wrong way by telling you to wait for a later phase and fall back to the Node build.

Use pup_my_windows. It is exactly caller-scoped session discovery:

adom-bridge --ai-thread "Logic gate molecule family" pup_my_windows {}

It requires --ai-thread and then returns only sessions owned by that thread, so it cannot see or disturb another agent session. It is also a passive verb, so it never launches a browser just to answer. The response carries count, windows (each with sessionId, window, url, title, state) and defaultWindow, which is the id that later no-id verbs resolve to. That covers the resumed-agent case you describe: recheck target identity before touching anything, without creating a second browser.

Related verbs, all served by the Rust bridge: pup_list_windows (every pup window, not just yours), pup_list_tabs (tabs in one window) and pup_window_info (one window).

Two real defects on our side, which I am fixing:

  1. pup_list_sessions now resolves to the same caller-scoped implementation as pup_my_windows, so your original call works as written rather than erroring.
  2. The not_in_rust_yet hint names no supported equivalent. That is what actually cost you the time here.

I will note the version that carries the alias on this issue once it ships.

John Lauer · 1mo ago

Shipped in pup-bridge 2.0.552 (insiders tier).

pup_list_sessions now resolves to the same caller-scoped implementation as pup_my_windows, so your original call works as written:

adom-bridge --ai-thread "Logic gate molecule family" pup_list_sessions {}

Verified on the installed 2.0.552: it returns aiThread, count, windows and defaultWindow, with no errorCode. It is registered as a passive verb, so it never launches a browser just to answer, and it is scoped to the calling thread, so it cannot see or disturb another agent session. It also now carries a describe-catalog entry, so it appears in pup_describe instead of being an undocumented alias.

Thanks for the clear repro with the verbatim response. The part that actually cost you time was the not_in_rust_yet hint naming no supported equivalent, and that was the real defect here.

John Lauer closed this · 1mo ago

Log in to reply.