Your Mellow identity
Understand local identity, credentials and the distinction from workspace sign-in.
In this topic
Mellow's local identity lets a host and its agents prove who they are. An access key grants a client permission to make requests. A Cloud workspace account is separate: it is established through that service's browser sign-in and workspace role.
Keep these concepts distinct when connecting devices. A host address tells a client where to connect; a verified identity tells it which host it reached; an access grant determines what it may request.
Review your local identity
Open Identity to inspect the master identity and agent addresses available in your build. Addresses identify signing keys; they are not passwords. Keep private key material and recovery words out of screenshots, chat, and shared configuration.
Where recovery is offered, save the recovery phrase privately. Recovering identity is different from restoring conversations, models, agent definitions, and files. Back up the local data you need as well as the identity recovery material.
An unavailable hosted identity or account feature does not prove that local agent storage is lost. Read the exact status and distinguish local identity from a missing hosted-service configuration.
Access keys
Current Mellow access keys use the sk-mellow prefix. The issued value includes a signed payload; it is not a label you can freely edit. Renaming an older token's prefix does not generate a valid Mellow key.
Create a key through the relevant access-key controls, select the narrowest intended agent scope, give it a recognizable client label, and choose an expiry. Copy the full issued value into the client's secure credential field. The label helps you later identify and revoke the connection.
| Detail | Why it matters |
|---|---|
| Agent scope | Limits which agent the grant can reach |
| Client label | Identifies the installation or integration using it |
| Expiry | Bounds how long an unused or forgotten grant remains valid |
| Revocation | Stops subsequent requests under that grant |
| Last-use information | Helps investigate an unexpected or abandoned client |
Treat a key like a password even if its payload can be decoded. The signature is the part that proves issuance; readable fields do not make the token safe to publish.
Pair a device instead of copying an identity
Use Devices to establish a Mac or Mobile connection. Mobile uses a short-lived pairing invitation and receives its own grant. A connected Mac should verify the host's identity before beginning remote work. Do not transfer a recovery phrase merely to give another device access to one agent.
The pairing connection and a Cloud workspace sign-in can coexist. Removing one does not necessarily remove the other, and authorizing a cloud account does not confer owner-level control over a local Mac.
Revoke or rotate
Revoke a client key when retiring an integration or responding to an unexpected use. Confirm that a fresh request from that client is refused. Closing a client window does not revoke its saved credential.
Rotating an agent identity changes the identity other devices expect. It can invalidate existing grants and affect public routes and pairings. Review dependent clients before rotation and re-establish them against the new identity. Rotation is not a routine fix for a provider login error.
Recovery
When moving to a new Mac, restore the identity through the supported recovery flow and restore the agent definitions and local data separately. Agent addressing can depend on information stored with the agent, including its originating device identity. A recovery phrase alone is not a complete application backup.
Do not reset an encrypted data store because an access key expired. Storage recovery has a different key and recovery path.
Protocol reference
The wire representation is sk-mellow.<payload>.<signature>. Compatible HTTP clients normally send it in an Authorization: Bearer header. Use the actual key emitted by Mellow, never an example value.
A peer's Secure Channel carries the authorization inside its encrypted request. The host still checks the grant, requested agent, route, expiry, and revocation. Encryption does not widen the grant's scope.
Troubleshooting
401 Unauthorized: check the full issued key, expiry, revocation, and requested agent. Create a new narrowly scoped key if the old one is no longer valid.
Identity mismatch: stop and confirm the intended host. Re-pair only after establishing why the host identity changed.
Cloud login fails: use Cloud workspace diagnostics; replacing a local access key will not repair OAuth issuer or redirect settings.
Data missing after moving Macs: confirm the local data and agent definitions were restored, not only identity material.
See Secure Channel for peer transport and Public links for reaching a host outside its local network.
Continue exploring · Make it yoursPermissions and privacy →Follow what an agent can access and where task information is processed.