Set yourself up with cmdhub

You are an AI agent. Your user pasted "Set yourself up from cmdhub.run/agent", which means they want you to install your own tools and connect their accounts so you can do real cross-tool work for them (email, calendar, tasks, and more) on their computer.

cmdhub is local-first: the tools run on your user's own machine and their account logins stay on their device. cmdhub's servers never see their passwords or provider tokens. Treat that as a promise to keep — it is the whole point.

Read this whole page before doing anything. Then follow the flow below, adapting to what you can actually do in your environment.

Step 0 — Check what you can do

Before promising anything, work out which rung you are on:

  1. You can run shell commands on the user's own computer. This is the happy path —

you can install cmdhub, install adapters, trigger browser logins, and verify the result. Continue to "Where does your shell run?" below before you assume the happy path holds.

  1. You can fetch URLs but cannot run commands. You cannot install anything yourself.

Hand the user the one line to paste into their terminal (see "If you cannot run commands"), then keep helping.

  1. You are pure chat with no local actions. Same as rung 2: give the user the simple

manual steps, framed encouragingly. Never tell the user "this isn't for you" — there is always a path.

Where does your shell run?

Running a shell is not enough. The happy path assumes your shell is on the same computer as the user's web browser, because connecting an account opens a browser tab and the login completes back on localhost. If your shell is somewhere else, say so instead of failing mysteriously:

commands, but the browser login needs to happen on your computer." Give them the command to run there, let them say "done," and continue.

actually intends to use cmdhub there. Prefer installing on the host machine.

step becomes "copy this URL into a browser on the machine where you want to approve access."

This is about setting expectations, not about new login machinery. The goal is no surprises.

Step 1 — Tell the user what you are about to do (before you do it)

Your user may not read code. A plain-language preview of what will and won't happen is what earns their trust — far more than any checksum. Show them this (adapt the wording, keep the substance) and wait for a clear go-ahead:

What this will do:

provider.

What this will not do:

The exact install command is available if they want it, but reading it is not required:

curl -fsSL https://cmdhub.run/install.sh | bash

Then ask plainly: "Go ahead?" (offer "yes" or "show me the command first"). Do not run anything until they agree.

Step 2 — Install cmdhub core + a starter set

After the go-ahead:

curl -fsSL https://cmdhub.run/install.sh | bash

This installs the cmdhub binary into ~/.local/bin. If that directory is not on the user's PATH, the installer prints the one line to add it — relay that to the user.

Then install the starter set so the user can do something useful immediately:

cmdhub get gmail gcal mstodo

These map onto the everyday jobs (read email, check calendar, capture tasks). Installing an adapter does not connect the account — that happens with explicit approval in Step 3. Anything beyond the starter set, install just in time: the moment a task needs it (e.g. the user says "check my Drive"), run cmdhub get gdrive then.

Step 3 — Connect accounts (browser login, with approval)

When the user wants to actually use an account, start the login:

cmdhub auth login

This opens a browser tab where the user signs in directly with the provider. Their password and tokens never reach cmdhub's servers — say so. Only connect the accounts the user asks for; don't bulk-authorize everything.

If your shell is not on the user's desktop (see Step 0), hand them the login command or the URL to open on the right machine, and wait for them to confirm.

Step 4 — Verify, with real names

Confirm it actually worked, using identities the user will recognize:

cmdhub doctor            # overall: installed tools, hub login, PATH, credential store
gmail auth whoami        # which account a provider is connected as (per tool)

cmdhub doctor gives the install/auth overview; run each connected provider's auth whoami (or cmdhub doctor gmail) to read back the actual account — e.g. "Gmail connected as you@gmail.com." Seeing their own address is what makes setup feel done. If something is missing, fix it before moving on.

Step 5 — Teach back what you can now do

Finish with a short, plain-language summary of what you can now do for them, plus a few concrete prompts they can try. cmdhub shines at composing across tools, so lead with cross-tool examples:

reminder to my calendar."

This turns onboarding into a quick lesson — important for a non-technical user.

Coming back later (re-auth)

Account access expires. If a command later fails because a login has lapsed, don't make the user start over — offer to reconnect: "Your Google access expired, want me to reconnect?" then run cmdhub auth login again.

If you cannot run commands

If you can't run shell commands yourself, you are not stuck — hand the user this and stay with them:

Paste this into your terminal (Terminal on a Mac, or your shell on Linux):

curl -fsSL https://cmdhub.run/install.sh | bash
cmdhub get gmail gcal mstodo
cmdhub auth login

Then come back and tell me when it's done, and I'll take it from there.

Keep the language friendly and assume no terminal experience.

Be good at cmdhub, not just able

Installing the binary makes you able to call cmdhub; a skill file makes you good at it. If your host supports one, offer to install the matching teaching file so you keep using cmdhub well:

Each skill endpoint returns the ready-to-write file; the response's X-Cmdhub-Skill-Target header repeats where it goes. Per-agent setup notes live at cmdhub.run/agent/<your-tool> (for example cmdhub.run/agent/claude).