CLI authorization

Connect the official SellApp CLI, choose stores, and disconnect your own access.

Connect the official SellApp CLI to work with your stores or create your first one. OAuth opens a browser for your approval and keeps access tokens out of command-line arguments. These CLI endpoints do not support general-purpose REST OAuth applications. Hosted MCP has its own browser connection and MCP-specific client registration.

Consent can allow commands that read or change real store data. It never grants additional store permissions: every request checks your current membership and permissions as well as the admin installation and token grant. Members can connect using their existing permissions. Owners manage membership and roles normally; there is no separate owner approval or CLI blocking control.

Log in and select a store

Use the CLI installation guide, then run:

sellapp login
sellapp stores list
sellapp stores use launch-lab
sellapp products list --limit 1

Sign in in the browser and approve account-wide access. The admin grant covers all stores you can access now or later, including stores you create. Declining consent leaves the connection unapproved. The CLI selects a single available store automatically; when several stores are available, choose one in the terminal or with stores use. stores list checks current access instead of relying on a saved store list.

Use sellapp login --no-browser when the CLI cannot open a browser. It prints an authorization URL that you can open manually on the same computer. The callback must reach the CLI's temporary local listener.

Inspect or disconnect

Open CLI access in your personal dashboard menu to see your connection, account-wide access, local agent access, and connection time when known. Disconnect revokes your connection and its complete token family. You can still disconnect after leaving every store. Store owners cannot disconnect another member's personal CLI connection.

You can also disconnect the current profile from the terminal:

sellapp auth logout

Logout revokes the server connection before deleting the local credentials. Removing a membership or restricting a role takes effect on subsequent requests; it does not grant access through a previously approved consent screen.

Token handling

The CLI uses Authorization Code with PKCE S256: a fresh verifier binds the browser approval to the process that started login. A random state value binds the callback to that attempt. Its registered callback is http://127.0.0.1/callback; the CLI chooses a temporary local port for each login. The public client ID identifies the supported registration. It does not prove that a request came from the official executable, and no client secret is embedded.

New profiles save the access and refresh tokens together in encrypted files on macOS, Linux/WSL, and Windows. No keyring setup is required. The CLI remembers your connection between terminal sessions. sellapp auth status reports the storage backend without exposing credentials. Refresh rotates the pair under a process lock. The CLI does not retry a credential after an uncertain exchange: a lost response may mean the server already used it. Authorize again after an invalid grant or uncertain refresh. Never print tokens, include them in URLs, or enable shell tracing around credentials.

The existing /oauth/authorize, /oauth/token, and /oauth/revoke protocol endpoints support the official CLI. Their low-level SDK interfaces remain available, but they are not an application registration service.

Diagnose failures

Error	What to do
`access_denied`	Consent was declined. Start a new login only if you want to approve the connection.
`invalid_client`	Check that you are using the official CLI. Contact SellApp support if the error persists.
`invalid_scope`	Check that you are using the official release and contact support if the error persists. Repeating the same rejected login will not resolve a CLI or server configuration mismatch.
`invalid_grant`	The code or refresh credential is expired, revoked, invalid, or already used. Start a new login.
Store `403`	Check the selected store, current membership, role permissions, and the connection grant. Credentials remain available for other stores.

Keep the request ID when available. Share the error category, not credentials or arbitrary OAuth response bodies.

Account-wide grant and local agents

The public V1 scope is admin. It enables the reviewed CLI and MCP operations across current and future accessible stores, constrained by your current role. It does not make a staff member a store owner. Store selection chooses the target of a request; it does not expand permissions.

A successful login can have zero stores. Run sellapp setup to choose or explicitly create one, or sellapp stores create --name "Launch Lab" --slug launchlab --use. Creation without --use leaves the CLI selection unchanged. API creation never changes your dashboard selection.

sellapp mcp uses this login to bridge local agents to hosted MCP. The CLI exchanges its access token internally for an MCP-only child token lasting at most five minutes, kept in memory without a refresh token. No second browser consent is needed. Logout or disconnect invalidates this access. Direct external MCP connections remain separately managed under MCP access.

Server-returned scopes are granted scopes. They are not a statement of your permissions in every store. When the response omits scopes, successful login still means the connection was saved; the CLI does not invent a grant.

Optional credential vault

New profiles use file storage regardless of how you installed the CLI. To select a backend deliberately, set SELLAPP_CLI_SECRET_STORE=file or SELLAPP_CLI_SECRET_STORE=keyring. Saved profiles retain their backend. A forced unavailable keyring fails with an error and does not silently fall back. Linux/WSL keyring use needs secret-tool and a running, unlocked Secret Service; ordinary file storage needs neither. File encryption is not OS-vault protection.