oo-cli
oo-cli exposes the oo command as OOMOL’s terminal-first interface for
official installs, OOMOL accounts, published packages, connector actions, cloud
tasks, files, logs, and managed skills.
If you are in Codex, Claude Code, or a regular shell session, start here before
you wire a lower-level API or MCP integration. oo is the terminal-first path
for trying published capabilities, handling auth and file transfer, managing
skills, and keeping the active CLI version current through the canonical
install guide and managed updates.
What oo-cli is good for
- Install the managed CLI binary through the official install guide, then keep it current with
oo update. - Sign in and switch between OOMOL accounts.
- Search packages and connector actions with one free-form query.
- Inspect package metadata and connector schemas before execution.
- Run authenticated connector actions directly from the terminal, including dry runs and JSON output.
- Create, list, monitor, and fetch Cloud Task runs.
- Install bundled or published skills into Codex and Claude Code.
- Upload, download, list, and clean up workflow files.
- Inspect persisted logs, manage CLI config, and generate shell completion scripts.
Install
Use the canonical install guide for the current platform-specific install and verification steps:
If you want your agent to handle the install for you, copy this prompt first:
Please help me install and verify oo-cli:
1. Read the install guide https://cli.oomol.com/install-guide.md
2. Follow it to check whether `oo` is already available. If it is missing, use the install command from the guide for this platform.
3. Run `oo --version` to verify the install.
4. Run `oo login`.
5. Tell me the best next command to run in oo-cli.
The install guide is the source of truth for the platform commands. This page
focuses on what to do after oo is available.
After a managed install, use oo update to move to the latest published
release, oo upgrade as an alias, and oo check-update when you only want to
see whether a newer release exists.
Quick Start
- Sign in:
oo login
- Search for a published capability:
oo search "generate a QR code"
- In Codex, use the bundled
ooskill:
$oo generate a QR code for the string OOMOL
oo login and oo logout are aliases for oo auth login and
oo auth logout.
Bundled Skills For AI Hosts
On the first oo launch, bundled skills are installed automatically into
supported local hosts that already exist.
- Codex:
${CODEX_HOME:-~/.codex}/skills/ooand the other bundled skill directories under${CODEX_HOME:-~/.codex}/skills - Claude Code:
~/.claude/skills/ooand the other bundled skill directories under~/.claude/skills
Current bundled skills solve different problems:
oo: routes practical tasks through existingoopackages or connector actions instead of inventing a local workflowoo-find-skills: searches the published OOMOL andooskill catalog, then installs one or more selected skillsoo-create-skill: helps turn an OOMOL package, connector action, block, or selected workflow into a reusable local skilloo-publish-skill: helps validate, publish, and share a finished local skill
The official install scripts and successful oo update runs refresh these
bundled skills automatically. For a manual refresh, use oo skills add.
oo skills update is for published oo-managed skills and does not update
bundled skills.
You can also install bundled skills explicitly:
oo skills install
oo skills install oo-find-skills
Use oo skills list to see the bundled, registry, and local skills currently
installed into supported agent hosts on your machine. oo skills preflight --agent <agent> checks whether a specific host can author local skills. The
current CLI supports hosts such as Codex, Claude Code, Hermes, WorkBuddy, Trae,
OpenClaw, and QoderWork when their local skill directories exist.
Main Workflows
Install or refresh the managed CLI
Use the managed install flow when you want official binary releases and a clear ongoing update path.
oo check-update
oo update
Use the official install scripts above for first-time installation. oo update
keeps that managed install current and refreshes bundled skills after a
successful update.
oo install [version] is also available for advanced managed-runtime cases,
such as reinstalling a specific CLI release. It is not the recommended
first-time install path for most users.
Search across packages and connector actions
Use oo search when the user intent matters more than the exact execution
path.
oo search "generate a QR code" --json
This command returns a mixed result set. Package results represent published
OOMOL capabilities. Connector results represent callable external service
actions and include fields such as authenticated and schemaPath.
Inspect a package or connector before execution
Use package inspection and connector search when you want the schema, metadata, or version details before you call anything.
oo packages info foo/bar@latest
oo connector search "send an email" --json
oo connector schema <serviceName> -a <action>
oo packages info resolves @latest for inspection. oo connector search
also caches connector schemas locally and reports the cached path in text and
JSON output. Use oo connector schema when you already know the target service
and action and want the exact JSON schema contract before sending input.
Run connector actions directly
Use the connector namespace when you already know you want an external service action.
oo connector search "send an email"
oo connector run <serviceName> -a <action> --dry-run --data @input.json
oo connector run <serviceName> -a <action> --data @input.json --json
oo connector run supports --dry-run for payload validation and can emit
structured JSON with --json.
Inspect a package and run it as a cloud task
Use the package and cloud-task namespaces when you want a direct programmatic path to a published block.
oo packages search "generate a QR code"
oo packages info foo/bar@latest
oo cloud-task run foo/bar@1.2.3 -b main --data @input.json
oo cloud-task list --status running --json
oo cloud-task wait <taskId>
oo cloud-task log <taskId>
oo cloud-task result <taskId>
oo cloud-task run requires PACKAGE_NAME@SEMVER, while oo packages info
can resolve @latest for inspection.
Move files into or out of a workflow
Use the file namespace when the task needs input artifacts or downloadable results.
oo file upload ./input.pdf --json
oo file list --status active --json
oo cloud-task run foo/bar@1.2.3 -b main --data @input.json
oo cloud-task wait <taskId>
oo cloud-task result <taskId>
oo file download <url>
oo file cleanup --json
Uploads expire after one day. Downloads default to the configured
file.download.out_dir, or ~/Downloads when that setting is not present.
Downloads also resume when possible and never overwrite an existing target
path.
Author, validate, and share a Skill
Use the skills namespace when a repeated API workflow should become reusable inside agent hosts instead of staying as one-off instructions.
oo skills init my-workflow --description "Reusable workflow for my team"
oo skills validate ~/.codex/skills/my-workflow
oo skills publish my-workflow --visibility private
oo skills share my-workflow
oo skills init creates a local skill in a supported agent host. validate
checks the skill directory before publication. publish turns the skill into an
OOMOL package, and share helps another agent or teammate install it.
Think of a Skill as a reusable execution contract, not just a prompt snippet. A good Skill preserves the selected Tools or connector actions, required inputs, calling order, checks, file handling, result shape, and failure path so future agents do not have to rediscover or guess the workflow.
Skill sources have different maintenance behavior:
- Bundled skills ship with
ooand are refreshed by install or update flows. - Registry skills come from published skill packages and can be searched,
installed, updated, and removed with
oo skills. - Local skills are authored in a supported agent host, validated locally, and can later be published and shared as OOMOL packages.
Common lifecycle:
oo skills search "generate images" --json
oo skills install "@alwaysmavs/gpt-image-2" -s "gpt-image-2"
oo skills preflight --agent codex
oo skills init my-workflow --agent codex --description "Reusable workflow for my team"
oo skills validate ~/.codex/skills/my-workflow
oo skills publish ~/.codex/skills/my-workflow --visibility private
oo skills share my-workflow
oo skills update my-workflow
Command Groups At A Glance
| Area | Key commands | Purpose |
|---|---|---|
| Install & Updates | official install scripts, oo update, oo upgrade, oo check-update, oo install [version] | Install a managed release and keep it current |
| Auth | oo auth ..., oo login, oo logout | Manage accounts and verify the active API key |
| Config | oo config ... | Persist CLI settings such as language and download directory |
| Search | oo search, oo packages search, oo connector search | Discover packages, connector actions, or both |
| Inspect | oo packages info, oo connector search, oo connector schema | Inspect metadata, versions, and schemas before execution |
| Execution | oo connector run, oo cloud-task ... | Call connector actions or create and monitor cloud tasks |
| Skills | oo skills ... | List, search, install, author, publish, update, and remove oo-managed skills |
| Files | oo file ... | Upload, download, list, and clean up local file-transfer records |
| LLM | oo llm config, oo llm json | Read account LLM config and generate schema-validated JSON |
| Logs | oo log ..., --debug | Inspect persisted debug logs and the current log directory |
| Telemetry | oo telemetry ... | Inspect or update privacy-constrained CLI telemetry settings |
| Shell | oo completion <shell> | Generate shell completion scripts |
When to use CLI vs MCP
Use the CLI when you are operating directly from a terminal or an AI coding host and want the fastest path to a working result.
Use MCP when you want to expose OOMOL capabilities as tools for external agent frameworks or MCP-compatible runtimes.