Support explicit account/gateway-entry selection for multi-account Grok Bot desktop sessions

[spencer-shadley]

Use case

Route independent jobs to different legitimately owned Grok Bot accounts without changing the desktop-selected account, logging in/out, or using another model as a messaging relay. The desktop account picker can retain more than one login.

This is a feature request to preserve exact account binding, not a request to remove the existing ambiguity safety check.

Source inspected

Pinned revision: b1c747132799707b0733bbdb9f0179c721c0f0c8.

• src/core/app-session.js, Git blob 9cdde1dc57d961b5df52260632d2e34f296085c9.
• src/core/gateway.js, Git blob dcc9721442fa1dcb5a79690820db4516b46ad352.

encryptedPayload() accepts version-2 descriptors only when Object.values(wrapped.entries) contains exactly one entry. Multiple entries throw AMBIGUOUS_ENTRIES; there is no explicit selector in the inspected loader.

sessionFromApp() also falls back to CURSOR_ACCESS_TOKEN on a descriptor-load error when that environment variable exists. That may be intentional for ordinary CLI use, but an exact-account integration must not resolve an ambiguous requested account by silently using an ambient token for a different account.

Hermetic reproduction (not a live-account failure report)

I reproduced the loader behavior against the byte-verified original upstream module using temporary synthetic Windows descriptors and an injected fake DPAPI function:

Fixture	Result
v1, one encrypted synthetic gateway	Loads
v2, one encrypted synthetic gateway	Loads
v2, two saved entries	AMBIGUOUS_ENTRIES before any decryption
v2, three saved entries	Same
v2, two entries plus a guessed activeEntryId	Same; this is not an asserted provider field
v2, no entries	EMPTY_ENTRIES
unknown descriptor version	UNSUPPORTED_VERSION

No real credentials, API requests, or active desktop account changes were used. A desktop picker containing two accounts does not by itself prove that the installed app writes this descriptor layout; that remains a live verification step.

Minimal failing fixture for loadGrokBotGatewaySession({ platform: 'win32', appData: TEMP_ROOT, env: {}, unprotectData: ... }), placed at TEMP_ROOT/Grok Bot/gateway-descriptor.json:

{"version":2,"entries":{"account-A":{"encrypted":"synthetic"},"account-B":{"encrypted":"synthetic"}}}

The ambiguity error occurs before Local State or DPAPI is needed.

Proposed contract

• An explicit opaque entry/account selector on relevant CLI/MCP operations, using the provider's real stable identifiers once verified, not entry order or a guessed email-to-entry mapping.
• Preserve fail-closed behavior if a requested entry is absent, ambiguous, unusable, expired, or conflicts with another credential source.
• In explicit-binding mode, no fallback to ambient CURSOR_ACCESS_TOKEN, the currently selected GUI account, or another gateway override.
• Credential source precedence remains documented for ordinary unbound CLI use.
• Bind a connection for an entire logical request; concurrent A/B requests must not mutate global desktop state.
• Non-secret binding evidence/diagnostics sufficient to verify the destination. Never print gateway tokens, raw descriptors, or decrypted credential payloads.
• Retain support for explicit gateway URL/token routing as a controlled alternative; document credential expiry/refresh behavior rather than promising permanent token reuse.

Happy paths should cover A/B concurrently and one account failing without altering the other's binding. Negative tests should cover missing selection, duplicate/ambiguous entries, a conflicting ambient token, and desktop selection changing mid-request.