One CLI: authenticated API access for agents, with workflows on top
A command-line tool to give your agents access to any app, create workflows and manage your One account.
At a glance
- What is it?
- One CLI wraps 750+ platforms behind a single command line so an agent can call Gmail, Stripe or Slack without managing OAuth tokens. It is a thin client over the One passthrough proxy, and the proxy is the part you cannot self-host.
- Who is it for?
- Adopt One CLI if your agents need to act on third-party SaaS APIs and you would rather pay for a managed credential broker than build one. Skip it if you need a self-hosted, offline, or air-gapped setup, or if your only requirement is reading public data that needs no authentication.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem One CLI solves: credentials, not HTTP
Calling a third-party API from an agent is rarely hard because of the HTTP request. It is hard because of everything around it: registering an OAuth app, storing refresh tokens, rotating them, handling per-platform rate limits, and remembering that Stripe nests errors differently from Gmail. One CLI exists to remove that layer. The README states the project gives agents authenticated access to 750+ platforms through a single interface, with no API keys to juggle and no OAuth flows to build.
The intended user is an engineer wiring an agent into real systems. The repository ships a `skills/` directory and the `one init` command installs an MCP server into Claude Code, Claude Desktop, Cursor, Windsurf, Codex and Kiro, so the same connection set is reachable from a chat harness or from a shell. That dual use is the actual pitch: one credential store, two entry points.
Every call routes through One's passthrough proxy
The README's architecture diagram is short and unambiguous. Your agent talks to One CLI; the CLI talks to the One API at `api.withone.ai/v1/passthrough`; the passthrough proxy talks to Gmail, Slack, Shopify, HubSpot, Stripe and the rest. One injects the credentials, applies rate limiting and normalizes responses. The connection key is the only secret your side holds.
This is a hosted broker, and it is worth being blunt about what that means. Your tokens live with One, not in your repository, and every API call transits their infrastructure. The upside is that the CLI itself stays small: `package.json` lists five runtime dependencies (`@clack/prompts`, `commander`, `open`, `pgserve`, `picocolors`, `smol-toml`), and none of them is an OAuth library. The CLI is a client, not an integration platform.
The local database dependencies are optional and version-sensitive. `better-sqlite3`, `@electric-sql/pglite` and `pg` sit in `optionalDependencies`, which is why the README notes that `one sync` needs Node 20 or above while every other command runs on Node 18.
Installing One CLI and sending your first email
The README offers two install paths. The one-shot version uses npx and requires no global install:
npx @withone/cli@latest init`one init` is interactive. It authenticates you through the browser or accepts an API key from the dashboard, asks which AI agents to configure, and installs the MCP server automatically. The global alternative is a normal npm install followed by the same init command:
npm install -g @withone/cli
one initNode.js 18 or newer is required. Once authenticated, connect a platform and confirm it registered:
one add gmail
one list`one list` prints the platforms you are connected to. The next step is finding the action you want, which the README does with a search filtered to executable actions:
one actions search gmail "send email" -t executeThat returns action identifiers. Read the documentation for the one you picked, then execute it with your connection key and a JSON payload:
one actions knowledge gmail <actionId>
one actions execute gmail <actionId> <connectionKey> \
-d '{"to": "jane@example.com", "subject": "Hello", "body": "Sent from my AI agent"}'The `-d` flag takes the request body as inline JSON. If the call succeeds you get the platform's response back through the proxy, and no OAuth token ever appeared in your shell history.
Flows: multi-step workflows stored as files in .one/flows
Single actions are the entry point; flows are where the tool becomes a small orchestration engine. A flow is a JSON definition with typed inputs, steps and conditions, created through `one flow create` and validated with `one flow validate`. The README's example looks up a Stripe customer and conditionally sends a Gmail welcome email, gating the second step on `$.steps.find.response.data.length > 0`.
On disk, flows live at `.one/flows/<key>/flow.json`, with an optional `lib/` folder for `.mjs` code modules, and can be grouped as `.one/flows/<group>/<key>/flow.json` and referenced as `group/key`. The legacy single-file layout `.one/flows/<key>.flow.json` still loads but is marked deprecated. The feature list is longer than the README's tutorial suggests: conditions, loops, while loops, parallel steps, transforms, sub-flows, pagination, bash steps and external modules, with `one guide flows` as the full reference.
Two design choices stand out. First, flows are files in your repository, not rows in a hosted database, so they diff and review like code. Second, connection keys auto-resolve when you have exactly one connection per platform, which keeps `one flow execute welcome-customer -i email=jane@example.com` short but hides a dependency: add a second Gmail connection and the shorthand stops being unambiguous.
Where One CLI is the wrong tool
The passthrough proxy is a hard dependency, and the README does not document a self-hosted or offline mode. If your environment forbids third-party SaaS in the request path, or if you need to run without network access to `api.withone.ai`, this tool does not fit. There is no fallback described.
Credential custody is the second boundary. Tokens are injected server-side, which is the feature, but it also means revocation happens in One's dashboard rather than in your own secret store. The README is explicit that the browser consent page tags the key with the install scope, project path, machine, OS user, CLI version, chosen harnesses and a per-install device id unless telemetry is off, and that the terminal prints what will be sent before the browser opens. That is a reasonable disclosure, but it is still metadata leaving your machine.
The third limitation is narrower and more annoying: on Node 18, `one sync` reports that its SQLite engine is not installed. Everything else works. If sync is central to your workflow, pin Node 20 or above rather than discovering this after setup.
One CLI compared with calling platform SDKs directly
The obvious alternative is what most teams do today: install the official SDK for each platform (`@googleapis/gmail`, `stripe`, `@slack/web-api`) and manage OAuth yourself. The difference is not the HTTP call, it is where the credential lifecycle lives. With SDKs you own the token store, the refresh logic and the per-platform error mapping, and you get no network hop you did not choose. With One CLI you own none of that, and in exchange every request goes through a third party.
A second alternative is a general workflow runner that executes HTTP requests against APIs you have already authenticated. Those tools assume the credential problem is solved and focus on orchestration. One CLI bundles both layers, which is convenient if you have neither and redundant if you already run a workflow engine and a secret manager. The honest framing: One CLI is a credential broker with a workflow engine attached, not an orchestration tool that happens to store keys.
Maintenance, licensing and upgrade cost
The repository is not archived and the last push was on 2026-09-15. Recent releases are close together: v1.55.4 on 2026-08-27, v1.56.0 and v1.56.1 on 2026-09-10. The published package version in `package.json` is 1.56.1, so the manifest and the release list agree.
Upgrade cost is low by construction. The CLI is distributed on npm as `@withone/cli`, so `npx @withone/cli@latest` picks up the newest build without touching your files, and global installs upgrade through npm. The version-sensitive part is the optional SQLite engine behind `one sync`, which is why the Node floor differs per command.
The licence is the gap. The repository metadata gives no licence identifier, and the README does not state one. Before adopting this inside a company, confirm the terms with the maintainers rather than assuming an open source licence applies. Nothing here is legal advice, but an unstated licence is a real procurement blocker.
Editorial conclusion
Adopt One CLI if your agents need to act on third-party SaaS APIs and you would rather pay for a managed credential broker than build one. Skip it if you need a self-hosted, offline, or air-gapped setup, or if your only requirement is reading public data that needs no authentication. Before committing, run `one config path` to confirm which config file wins in your repo, check that your Node version supports `one sync`, and read the browser consent screen carefully: it names the API key and tags it with the install path, machine, OS user, CLI version and harnesses, and that tag is what you will later revoke from Settings → API keys.
Frequently asked questions
What is a CLI versus an API?
An API is the interface a program calls; a CLI is the command you type. One CLI sits on both sides of that line, since it is a command line tool that calls the One API at api.withone.ai/v1/passthrough on your behalf.
What is CLI versus UI?
A UI is operated by clicking in a window, while a CLI is operated by typing commands. One CLI is the typed interface; the browser dashboard at app.withone.ai is the UI where you manage API keys and revoke them under Settings.
How does a CLI agent work?
In this project the CLI installs an MCP server into harnesses such as Claude Code, Claude Desktop, Cursor, Windsurf, Codex and Kiro, and the agent then searches for actions and executes them through the One passthrough proxy using a connection key instead of raw credentials.
What is the full form of CLI?
CLI stands for command line interface, which is how the README describes the tool: commands like one init, one add and one actions execute are run in a terminal rather than through a graphical window.
Community notes