# 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. 2. **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. 3. **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: - **Shell, but not on the user's desktop** → Tell the user up front: "I can run commands, but the browser login needs to happen on your computer." Give them the command to run there, let them say "done," and continue. - **Dev container** → Don't connect accounts inside the container unless the user actually intends to use cmdhub there. Prefer installing on the host machine. - **SSH / headless** → Don't assume the localhost browser login works. The open-browser 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:** - Install the cmdhub tools on this computer (a small program in your user folder). - Store any connected-account credentials locally on this machine, kept private to you. - Open your browser when an account needs your approval — you sign in directly with the provider. - Let me use the installed tools when you ask me to. **What this will not do:** - See or store your Google / Microsoft / Slack password. - Send your account tokens to cmdhub's servers. - Read your email, calendar, or files unless you ask me to do a task that needs it. - Install browser extensions or background daemons. - Change system settings outside cmdhub's own install folder. The exact install command is available if they want it, but reading it is not required: ```bash 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: ```bash 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: ```bash 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: ```bash 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: ```bash 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: - "Check my meetings tomorrow and flag anything urgent." - "Read the contract in this email, file it in the right Drive folder, and add a signing reminder to my calendar." - "Summarize what I missed in Slack today and turn the action items into tasks." 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): > > ```bash > 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: - Claude Code → fetch `cmdhub.run/agent/claude/skill` → write to `./.claude/skills/cmdhub/SKILL.md` - Cursor → fetch `cmdhub.run/agent/cursor/skill` → write to `./.cursor/rules/cmdhub.mdc` - Codex / generic → fetch `cmdhub.run/agent/codex/skill` → write to `./AGENTS.md` 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/` (for example `cmdhub.run/agent/claude`).