Sign In to the Cheerful CLI and Connector

A static API key is a credential that outlives the person who created it, carries whatever permissions it was minted with, and cannot be told apart from any other holder of the same string. For a product whose account boundary is "the campaigns and mailboxes this person may see", that is a worse fit than it first looks: a key shared across a team quietly becomes an account nobody owns, and a key that leaks is indistinguishable from its owner.

So Cheerful authenticates machines the same way it authenticates people. The CLI signs you in through the browser and holds a session; the MCP connector runs a standard OAuth flow and holds a token issued to that specific client for your account. Both carry your permissions exactly — no more, and no less — and both stop working when your session is revoked.

A browser sign-in works on your own machine and does not work on a build agent. That is a real limit rather than a detail: unattended use — CI, cron, a shared runner with no browser — is not supported today. The CLI is built for interactive work at a terminal, and a scheduled job that shells out to it will fail the first time its session needs refreshing.

If that is what you need, say so. Machine credentials are a design question with real consequences for a product that holds other people’s inboxes, and the version worth building is the one shaped by what people are actually trying to automate. Get in touch with the job you are trying to run.

A CLI session and a connector token both carry your own permissions, and that is the whole security model: there is no elevated machine scope, and no way to grant a script more than the person running it has. In practice that means a session reaches your own campaigns, lists and mailboxes, plus anything your teams share with you — and reaches nothing else.

It also means the answer to "why can’t this script see that campaign" is usually an access answer rather than a bug. The connector’s account_read tool and the CLI’s cheerful auth whoami both report which account is acting and what it is entitled to, which is the fastest way to tell a permissions problem from a broken call.

The MCP connector is read-only, so the worst a leaked connector token can do is read. A CLI session is not read-only — it can create and launch campaigns, send email and spend credits, because it drives the same API the web app does. So the honest asymmetry is: connect the connector freely, and treat a signed-in terminal the way you would treat a logged-in browser tab.

A key is often the wrong question. If the goal is to get Cheerful’s data in front of an assistant, the MCP connector already does that with no credential to manage. If the goal is to move campaign state into a spreadsheet or a project tool, the built-in integrations — Google Sheets, Airtable, Monday, Shopify, Slack — write that data on a schedule without anything to script.

What remains genuinely unsolved is unattended automation against your own account: a nightly export, a health check, a scheduled report. That is the case machine credentials would exist for, and it is the one worth telling us about.

The CLI keeps its session in a config file in your home directory and refreshes it automatically. cheerful config show prints where that is and which API host it is talking to. Deleting it signs you out; so does cheerful auth logout.

The MCP connector stores nothing on your machine at all — the token lives in whichever client you connected, and removing the connector there is what revokes it.