app

Pup - the AI's own browser

Public Made by Adom

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.

skillspuppuppeteerbrowseradom-bridgebridgepup-bridge
Overview Files Skills Discover Packages Releases Dependencies Issues17 Breadcrumbs Pull Requests1 Activity
Open general

X.com 'Continue with Google' login: pup_click stops opening the GSI popup, popup not tracked, X rejects login; forced a real-mouse fallback

John Lauer · 14d ago

Summary

pup cannot sign into x.com with "Continue with Google" without taking over the user's real mouse, and even with the real mouse X refuses the login. pup is supposed to drive every browser flow in the background; here the AI had to fall back to desktop_click (moving the user's cursor) and it still failed. The user (John) called the mouse takeover "horrific", so that is the main bug.

Repro (2026-10-27, AdomLapper, extension lane, no debug port)

  1. pup_open_window {url:"https://x.com/i/flow/login"}. The pup profile is already signed into Google (pup_google_accounts lists the accounts).
  2. "Continue with Google" is a Google Identity Services iframe (accounts.google.com/gsi/button) at about (846,466) CSS px.
  3. pup_click {x:846,y:466} (reports isTrusted):
    • 1st time: a Google account-chooser popup opened and showed up in pup_list_windows as <session>-2.
    • Every later time (after a reload, a navigate, or in a new window): nothing happens. No popup, no FedCM, and the page doesn't change.
    • Clicking the wrapper DIV from pup_eval doesn't do anything either (it isn't trusted).
  4. Fallback with the real mouse, desktop_click on the window: the popup does open, but as the window "Sign in - Google Accounts - Google Chrome for Testing", and pup_list_windows doesn't list it (it's only visible through desktop_list_windows). So it can't be driven with pup_eval or pup_click.
  5. Picking the account in that popup with a real desktop_click: X returns "An unexpected error occurred. Please try again." Reproduced twice.
  6. Separate trap: pup_google_signin {account} called while the GSI popup was open sent the main window to mail.google.com, which broke the opener.

Expected

  • pup_click on a GSI/OAuth iframe opens the popup every time, not only the first time.
  • OAuth popups opened from a pup tab are tracked by pup (listed as a session/tab) so they can be driven in the background.
  • pup_google_signin should finish an open GSI popup (pick the account inside it) rather than navigating the opener away.
  • If X blocks Chrome for Testing logins, say so in a hint (e.g. pup_login / login-recipes/x.com.md) so AIs stop retrying and never reach for the mouse.

Workaround used

Showed the page in the user's real Chrome through nbrowser_open_window (that profile is already signed into X). That works, but the user asked for pup.

Ask

A background-only X (and generally GSI-button) login path in pup, plus a login-recipes/x.com.md.

2 Replies

John Lauer · 14d ago

Fixed what was pup's, found what is X's. On insiders as 2.0.735.

I reproduced this on AdomLapper (John's pup profile, signed in to Google) entirely in the background, with no real mouse.

pup's part, fixed:

  1. Wrong click target. The click went to Google's accounts.google.com/gsi/button frame, which sits just below X's visible "Continue with Google" button, so clicks there do nothing. A background pup_click on X's own button (text:"Continue with Google") opens Google's account picker every time.
  2. Slow popup pickup. pup adopted that popup as <window>-2, but only after 30 to 40 s, so the AI looked, saw nothing, and reached for the mouse. 2.0.735 adopts a popup a click opened within about 3 s (measured on ConfRoomROG), and the click's answer carries _popupHint saying where it will appear. Picking the account inside the popup with pup_click {window:"<window>-2", text:"<email>"} works.

X's part: after a clean background flow (X's button, the popup, [email protected] picked inside pup), X still answers "An unexpected error occurred. Please try again." X refuses a fresh sign-in from pup's browser; no click change gets past it.

The way in (2.0.735): pup_import_browser_logins {sessionFor:"x.com"} brings the user's existing X session over from their own Chrome or Edge:

  • It goes through the same Adom Bridge consent and Windows prompt as the password import.
  • Only that site's cookies come over; they are set in pup's browser and never printed.
  • If more than one profile is signed in, the answer is several_sessions with the list, and the AI asks which account and passes sourceProfile.

It's documented in the new login-recipes/x.com.md and the pup-import-logins skill.

Not done in this issue: pup_google_signin still navigates the opener when another site's Google popup is open. The recipe now says not to call it then.

Leaving this open until the session import is confirmed on John's laptop.

John Lauer · 13d ago

Fixed and proven on AdomLapper (pup 2.0.738, insiders)

X signs in as @lauer_john in pup, through the new nb-coordinated session import. No Windows Hello, no cracking of Chrome's sealed store.

What changed. pup's pup_import_browser_logins {sessionFor} no longer calls ab's desktop_decrypt_browser_credentials (retired on the Chrome 156 ABE breakage, adom/adom-bridge#254). It now calls nb-bridge's nbrowser_export_site_session, which reads that one domain's cookies from inside the user's real signed-in browser (chrome.cookies), writes them to an owner-only file on the machine, and hands pup only a path plus counts. pup reads the file locally, sets the cookies into the adom-you browser over CDP, and tells nb to drop the handoff. No cookie value ever crosses the relay.

The run (2026-10-29):

  • pup_import_browser_logins {sessionFor:"x.com"} -> 13 cookies set, 0 refused, no Hello.
  • Reloaded x.com/home: signed in. DOM read: profileHref:/lauer_john, account switcher John Lauer @lauer_john, Home timeline populated. Screenshot sent to John.

The bulk password import (every saved login, not just one session) rides the sibling verb nbrowser_export_saved_logins (nb#55): Chrome's own consented export, one Windows Hello. That half needs a human at the machine, so it gets proven when John runs it for real.

Leaving this open until the password half is also proven on a real Hello; the session case that this issue was filed for is done.

Log in to reply.