Authentication

Sign in to Lobby automation without copying browser cookies or agent capabilities.

Local CLI and MCP

Run browser login once for each Lobby origin:

lobby login

Confirm the terminal code and approve in your browser, then select your account in the terminal. A sole account is selected automatically; --account ID chooses one explicitly. --email EMAIL keeps the legacy interactive email-code flow.

The CLI verifies the identity with Lobby and saves an owner-readable session in the local user’s configuration directory. Browser sign-in is separate. Never copy the saved session into a repository, command argument, MCP configuration, prompt, or another user’s account.

Run lobby logout to revoke the CLI session at Auth and remove it locally. An unsuccessful server logout retains the local credential so you can retry. Sign in again after the session expires. For a non-production deployment, pass the same --site HTTPS_ORIGIN to login and later commands; login and logout also accept --auth-url HTTPS_ORIGIN when that deployment uses another Auth origin.

Inspect the CLI identity

lobby auth status

This reads the saved CLI session and returns site, user (id, email, name), account (id, role), and observedAt. It never creates an account or returns a cookie. A missing local session requires lobby login; HTTP 401 means the session or membership is unavailable. An authentication outage returns an error rather than an empty account.

{"site":"https://lobby.abloatai.com","user":{"id":"user-id","email":"you@example.com","name":"You"},"account":{"id":"account-id","role":"member"},"observedAt":"2026-10-09T12:00:00.000Z"}

observedAt is the response timestamp. Lobby’s existing identity reader can reuse successful session and membership answers for up to five minutes while Auth is rate-limited or unavailable. An explicit denial clears the relevant cached answer. This is not an immediate-revocation guarantee during an outage.

Organizations and invitations

Auth owns organization membership, invitations, acceptance, roles, and account switching. Open Members through Lobby to reach the shared Auth service. Owners and admins can invite; only owners can change member/admin roles. The invited person must accept. A matching email domain does not grant membership.

The CLI has its own session. Switching organizations in a browser does not switch the CLI’s organization. Use lobby accounts list and lobby accounts switch ACCOUNT_ID to choose the CLI account, then lobby auth status to inspect it. Invitation commands are documented in Accounts and Members. When a session has no active organization, Lobby resolves the first organization whose membership Auth proves.

lobby logout revokes only the CLI session, then deletes its local cookie file. Separate browser sessions remain signed in.

Account membership and each person’s GitHub repository permission are checked by the server. A conversation ID selects scope; it does not grant access. Discover authorized IDs with:

lobby conversations list

Inside a Lobby agent

Lobby supplies short-lived, conversation-scoped authority to eligible agents. Commands inherit the account, repository, conversation, run, and actor; omit --site, --conversation, and --repository when the command says scope is inherited. The agent cannot turn that capability into broader or durable access.

Which credential is which?

Use Model Key Connections for private CLI input and status reads. Logging out of the CLI does not disconnect these integrations. Each has its own disconnect/revocation behavior. See identity and access and development environments.

API keys

The member API-key implementation adds cookie-free account and VM-status reads through Better Auth. It requires a coordinated Auth migration and release before deployment. Keys bind one person, account and explicit repositories. Logout does not revoke them. Service accounts and lifecycle writes remain separate work. Cookies and runner capabilities do not authenticate the versioned API.