nbrowser_open_window without a profile silently uses the active one; refuse when several identities are connected

Overview Files Skills Discover Packages Releases Dependencies Issues7 Breadcrumbs Pull Requests1 Activity

Closed feature request

John Lauer · 27d ago ·closed by John Lauer

An agent opened a window in the wrong Chrome profile and got as far as Google's account chooser for a forum sign-in before it noticed. Nothing was posted under the wrong account, but nothing in nb stopped it either.

What happened

On John's laptop (AdomLapper), four Chrome profiles have the extension: [email protected] ("John Personal"), [email protected] ("adom.inc", Default), [email protected] ("adom.inc", Profile 2), plus one that has no email. The task was to post on the Autodesk forum as John.

nbrowser_status returned {"ok":true, "browser":"chrome", "sessions":[]...} with no profile list, although its _hint says it is the "connectivity check: connected profiles + active browser".
nbrowser_open_window {sessionId, thread, purpose, url} with no profile succeeded and opened in whichever profile was active: [email protected].
The forum showed signed out; "Sign in" led to Google's chooser offering only [email protected]. Signing in there would have created or used the wrong Autodesk identity and posted as the wrong person.

The agent did skip the documented preflight (nbrowser_profiles first, then pass profile). But nb already refuses a window without sessionId/thread/purpose (session_unregistered) because the cost of a mistake is high. Driving the wrong account is a bigger mistake than an untracked window.

Ask

Refuse a missing profile when more than one identity is connected. nbrowser_open_window (and open_tab) without profile should fail with a code like profile_required, listing the connected profiles as browser:email + displayName, with a hint naming the exact profile value to pass. With exactly one identity connected, defaulting is fine.
nbrowser_status should list the connected profiles, the way its own hint promises: key, email, displayName, asleep, active. Today only nbrowser_profiles does.
Say which identity a window is in, in the nbrowser_open_window response (profile, email, displayName), so an agent sees "[email protected]" right away instead of discovering it at a sign-in page.
Minor: nbrowser_profiles returned three rows with no email or displayName, and [email protected] twice (once Chrome Default, once marked asleep with displayName "Profile 1"). A note on what those rows are (another browser? stale?) would help an agent choose.

🤖 Generated with Claude Code

1 Reply

John Lauer · 27d ago

Fixed in nb 0.16.39 (insiders), all four asks. Verified on AdomLapper with your three Chrome identities connected, and on ConfRoomROG: full battery 88/88 on both.

1. An unnamed open is refused when several identities are connected. nbrowser_open_window and nbrowser_open_tab with no profile and no session pin now fail with profile_required when more than one signed-in identity is connected. Live from your laptop:

3 signed-in identities are connected, so 'nbrowser_open_window' will not guess which one to act as: chrome:[email protected], chrome:[email protected], chrome:[email protected]. Pass profile:"".

The reply carries profiles[] with the key, email, the label you see in Chrome and the profile directory, and _next spells out the retry for each one. With exactly one identity connected, defaulting still works, so a single-profile machine is unaffected.

Ordering matters here and I got it wrong twice before it was right. The guard now runs after the registration check (a call with no sessionId still gets session_unregistered first) and before the session pin is written (my first cut pinned the session, then saw a pin and skipped itself). The battery covers both.

2. nbrowser_status lists the connected profiles, as its own hint always promised: key, email, displayName, active, origin and extension version, plus asleepProfiles for the ones on disk that are not connected, and activeProfile.

3. Every window and tab reply says which identity it acted as: profile, email, displayName, and actingAs as one line, for example adom.inc <[email protected]>. No more finding out at a sign-in page.

4. The odd rows explain themselves. A row with no email now carries a note: either pup's own browser (those are also marked origin: "pup" and are never the default), or an identity that has not resolved yet. The note also says the same email legitimately appears once per browser, since chrome:you@x and edge:you@x are different windows with different cookies: that is your duplicate [email protected].

John Lauer closed this · 27d ago