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

  1. Sign in:
oo login
  1. Search for a published capability:
oo search "generate a QR code"
  1. In Codex, use the bundled oo skill:
$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/oo and the other bundled skill directories under ${CODEX_HOME:-~/.codex}/skills
  • Claude Code: ~/.claude/skills/oo and the other bundled skill directories under ~/.claude/skills

Current bundled skills solve different problems:

  • oo: routes practical tasks through existing oo packages or connector actions instead of inventing a local workflow
  • oo-find-skills: searches the published OOMOL and oo skill catalog, then installs one or more selected skills
  • oo-create-skill: helps turn an OOMOL package, connector action, block, or selected workflow into a reusable local skill
  • oo-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 oo and 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

AreaKey commandsPurpose
Install & Updatesofficial install scripts, oo update, oo upgrade, oo check-update, oo install [version]Install a managed release and keep it current
Authoo auth ..., oo login, oo logoutManage accounts and verify the active API key
Configoo config ...Persist CLI settings such as language and download directory
Searchoo search, oo packages search, oo connector searchDiscover packages, connector actions, or both
Inspectoo packages info, oo connector search, oo connector schemaInspect metadata, versions, and schemas before execution
Executionoo connector run, oo cloud-task ...Call connector actions or create and monitor cloud tasks
Skillsoo skills ...List, search, install, author, publish, update, and remove oo-managed skills
Filesoo file ...Upload, download, list, and clean up local file-transfer records
LLMoo llm config, oo llm jsonRead account LLM config and generate schema-validated JSON
Logsoo log ..., --debugInspect persisted debug logs and the current log directory
Telemetryoo telemetry ...Inspect or update privacy-constrained CLI telemetry settings
Shelloo 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.

References