Settings, auth, and scopes
CLI login, PAT fallback, token bundles, active orgs, and per-vault grants.
Bearer types
LiquidLM accepts two bearer classes. Session bearers come from interactive login and represent a user. Static API tokens use the lqlm_ prefix and are intended for automation, direct API calls, and MCP clients that cannot launch the CLI.
The recommended MCP setup is CLI-managed stdio. The MCP client launches liquidlm mcp serve, and the CLI refreshes the logged-in session token and forwards the active organization header for each request.
- Use liquidlm login for local development and agent clients that can run the CLI.
- Use PAT plus Authorization: Bearer only for headless clients, CI, or direct HTTP integrations.
- Session-only endpoints, such as token management, reject PATs even when the PAT has a high bundle.
Bundles and custom scopes
Tokens are granted a bundle or an explicit custom action set. Named bundles expand into REST and MCP actions: viewer for read surfaces, editor for write surfaces, maintainer for operational management, and owner for irreversible or account-level actions.
Custom scopes list explicit API and MCP actions. The server rejects unknown actions and session-only actions during token create or update, and every minted token must be a subset of the caller's expanded action set.
- The Connect page disables bundle choices and custom actions above the caller's ceiling.
- The server still enforces the elevation guard; UI checks are only guardrails.
- api.account.self is the narrow self-description route available to every authenticated bearer.
Active organizations
Session requests resolve an active organization from route vaults, the active-org header, or the user's stored default. PATs are different: they are bound to the organization stored on the token row.
When a request includes vault IDs, the resolver validates that the vaults belong to one organization and that the bearer can read them. Mixed-org filters reject instead of picking an arbitrary org.
- The CLI stores activeOrgId and sends it from mcp serve.
- PAT requests without an active-org header use the PAT's stored organization.
- A PAT with a mismatched active-org header is rejected.
Per-vault grants
Action scopes decide which verbs a bearer may use. Vault grants decide which vaults those verbs can touch. Both checks have to pass.
A token can read a vault without write access, and write grants are checked separately for upload, mutation, and agent write operations.
- Vault filters narrow search, list, graph, and chat retrieval.
- Write-capable tokens still cannot write outside their allowed write vaults.
- Vault-only collaborators can receive write verbs for shared writable vaults even without a broad org role.
Use the smallest token that works
For an integration, start with viewer and explicit vault grants, then add editor or custom actions only when the integration needs to write.