SDK change: blocked_on_user is a required structured response (never bare-timeout a human wait)

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 · 2mo ago ·closed by John Lauer

From ab wiki #142/#137 (John): a new HARD rule in BRIDGE_SDK.md, shipping in the ab 2.1.30 pkg. Any bridge verb blocked on a HUMAN action - a permission prompt, an app modal, a login/2FA wall, an OS dialog - MUST return a structured non-terminal response naming it, whether or not it is streaming progress: {success:false, errorCode:"blocked_on_user", stillRunning:true, blockedBy:"", _hint:"<how to wait/retry>"}. Never a bare transport error or an HTTP timeout while a human decision is pending. This mirrors ab-core's own needs_approval / timed_out+stillRunning / bridge_installing_deps contract, so a cloud AI can always tell 'still working' vs 'waiting on the user' vs 'genuinely failed'. Nothing required of pup for the #142 deps-install case (ab-core handles that with bridge_installing_deps as of 2.1.30) - this is the general rule for any of pup's own verbs that can park on a human (e.g. a CfT profile login, a site's 2FA).

1 Reply

John Lauer · 2mo ago

Shipped in pup 2.0.397 (insiders, 2026-09-05) and verified on arav-rog and winvm.

What changed:

src/consent.js: a consent registry behind the approval toasts (pup_credential_reveal, pup_fill_card). The verb waits in-verb for at most 45 s (under every ab budget), then answers {success:false, errorCode:"blocked_on_user", stillRunning:true, blockedBy, consentId, remainingSec, _hint} while the toast stays up for its 120 s lifetime. Re-calling the SAME verb with the SAME args re-attaches to the pending toast (no second toast) and collects the decision exactly once; a toast timeout retracts the sticky toast (notify_dismiss) and hands over consent_timeout on the next re-call. Gate: tests/check_consent.js (in ship.sh).
pup_assisted_click: the wait for the user to focus the window is capped at 45 s per call and answers blocked_on_user (stillRunning:false, reason:"user_not_ready"), the caller re-issues it when the user is back.
pup_login {submit:true}: after the submit, pup looks for the walls only a human can pass (one-time-code input, authenticator / verification-code text with no password field, reCAPTCHA / hCaptcha / Turnstile / Arkose iframes, "prove you are human" text) and answers blocked_on_user (reason: two_factor | captcha, stillRunning:false, output.submitted:true) with the raise-the-window hint, instead of success:true.
pup_readiness.active[] rows carry blockedOnUser:true for open consents and dialogs, and phase:"consent_decided" for a click nobody has collected yet; pup_describe.progressContract.blockedOnUser states the contract (45 s in-verb, 120 s toast lifetime, re-attach rule).
Skills: pup (reveal paragraph), pup-progress, pup-vendor-login updated.

Not changed: pup_dialog's dialog_action_required (that one is the AI forgetting action, not a human wait) and the deps-install path (ab-core's bridge_installing_deps, seen working on arav-rog today: the first verb answered bridge_installing_deps at 0 s and 4 s, and pup was up at 8 s).

John Lauer closed this · 2mo ago