Log in

Documentation

Everything you need to get started with ooda.

Also available as plain markdown for LLMs.

Getting started

ooda lets your team publish prototypes, tools, and sites to the web safely, from any agent. Your coding agent runs the ooda CLI, and ooda publish ships a built site to a private, shareable URL.

The setup depends on where your agent runs:

  • Local agents run on your computer, for example Claude Code in your terminal, Cursor or the Codex CLI.
  • Cloud agents run in a sandbox, for example Claude Code on the web, Codex, ChatGPT or Claude.ai.

Local agents

1. Install the CLI and sign in. You do this once. The session stays on your computer.

$ curl -fsSL https://ooda.run/install | sh
$ ooda login

macOS and Linux. No Node.js needed.

ooda login emails you a sign-in code. If you belong to several teams, see Several teams.

2. Give your agent the ooda skill and publish. Open your agent in the folder of your site and tell it:

Fetch https://ooda.run/skill.md and follow its instructions. Then build this project, publish it with ooda publish, and share the live URL with me.

You can also publish yourself: from a built site, run ooda publish.

Cloud agents

1. Let the sandbox reach ooda. Most sandboxes block ooda by default. Set up the network once for each environment:

  1. Open the environment settings of the cloud session.
  2. Set Network access to Custom.
  3. Add ooda.run and *.ooda.run to Allowed domains, one on each line.
  4. Select Also include default list of common package managers, so that the agent can install the CLI with npm.

The setting is per environment. It applies to Claude Code on the web, the desktop and mobile apps, and claude --cloud.

2. Add an access token to the environment. The sandbox keeps no session, so a sign-in does not stay between sessions. An access token signs the CLI in with no email code:

  1. In the dashboard, open Account and click Create token.
  2. Select only the scopes the agent needs. To publish, Read sites and Publish sites are sufficient.
  3. Copy the OODA_TOKEN=… line. The token appears only once.
  4. Paste the line into the environment variables of the sandbox. Then start a new session, because a running session does not get the variable.

In Claude Code on the web, the field is Environment variables in the environment settings. In Codex, use Environment variables, not Secrets: Codex removes secrets before the agent starts. ChatGPT and Claude.ai have no environment variables, so use an email code.

If you belong to several teams, choose a Default organisation when you create the token, or add OODA_ORG_ID=<org-id> on a second line. A token acts as you, so everyone who can use the environment can use the token. Revoke a token on the Account page if it leaks.

3. Give your agent the ooda skill and publish. Tell it:

Install the ooda CLI with npm install -g @oodarun/cli, then fetch https://ooda.run/skill.md and follow its instructions. Then build this project, publish it with ooda publish, and share the live URL with me.

The CLI reads OODA_TOKEN by itself, so the agent does not run ooda login. Run ooda whoami to see the account and the team.

Without a token: sign in with an email code. Tell the agent to sign you in with ooda login and to ask you for your email and the code from your inbox. The agent requests the code, you paste it into the chat, and the agent verifies it. Do this in each new session:

$ npm install -g @oodarun/cli
$ ooda login --email [email protected] --json
$ ooda login --email [email protected] --code 123456 --json
$ ooda publish ./dist --json

A new code cancels the earlier codes, so paste the code from the latest email. If your account is in several teams, the CLI selects one and lists the others. Add --org <org-id> to the verify step to choose, or run ooda switch <org-id> after it.

A sandbox installs the CLI with npm, not with the standalone installer. The sandboxes include Node.js and allow the npm registry, and the Node CLI uses the proxy that HTTPS_PROXY names. Some sandbox proxies do not work with the standalone binary. If an older CLI fails with fetch failed, update it, or set NODE_USE_ENV_PROXY=1.

Agent skill

The ooda agent skill teaches your agent to publish sites, manage them and sign in, with no questions to you. The skill is hosted at ooda.run/skill.md, so it needs no install. The prompts above tell the agent to fetch it.

To load the skill automatically in every session, install it into the agent's skills directory with the skills CLI:

# Global (all projects)
$ npx skills add toy-studio/ooda-skills -g

# Or per-project
$ npx skills add toy-studio/ooda-skills

Source and details: github.com/toy-studio/ooda-skills.

Publishing sites

Publish a built static site to a gated, shareable URL with one command: ooda publish.

How it works

  1. Build your site (e.g. npm run build)
  2. ooda publish detects the build output directory and uploads it
  3. Your site is available at a {slug}.ooda.run URL, gated by your access policy

Every publish creates a new version. Previous versions are kept and accessible.

Any framework that produces static output works — Vite, Astro, Next.js (static export), and more. ooda publish detects your build output directory (dist, build, out, etc.).

ooda.json

ooda.json is the site configuration file. ooda publish reads the site's metadata from it, and writes the site's addresses back into it.

{
  "name": "My Cool App",
  "description": "A React dashboard for analytics",
  "tags": ["dashboard", "react"],
  "color": "#0f766e"
}

name

Human-readable site name (e.g. "My Cool App"). Shown in the dashboard instead of the site slug when set.

description

Short description of what the site is. Shown in the dashboard alongside the name.

tags

Keyword tags for the published site, used for filtering and search.

color

Brand colour ("#rrggbb"). The dashboard tints the site's card with it.

secrets

A manifest of the env vars and secrets the site needs, so ooda secrets check can prompt for the missing ones.

slug, siteName, urls

Written back by ooda publish — the resolved {slug}.ooda.run address and, when your org has short addresses, the {siteName}.{org}.ooda.run one. Keep them in the file so re-publishes stay on the same URL.

Access control

Every site is gated. By default a site requires a team login; you can make any site public or password-protected, per site or as an org-wide default. Site passwords are encrypted at rest. Manage access from the dashboard or with ooda sites access.

CLI commands

$ ooda publish [path]

Publish a built static site to a shareable {slug}.ooda.run URL. Non-interactive; --json supported.

$ ooda sites [list|access|password|delete]

List and manage your published sites — set access (public / password / login), reveal a password, or unpublish.

$ ooda secrets [set|list|rm]

Manage env vars & secrets for your published sites. --env values reach a site's page as window.__OODA_ENV__; true secrets never reach the browser. No reveal in the CLI — an admin reveals in the dashboard.

$ ooda login  ·  ooda whoami  ·  ooda logout

Sign in with an email code (--email/--code for agents/CI), check the current session, or sign out. In a sandbox or CI, set OODA_TOKEN instead.

$ ooda orgs  ·  ooda switch <org-id>

List the teams your account belongs to, and choose the one that later commands act on. You join another team in the dashboard.

Managing your team

On ooda, sites belong to a team (an organisation). Team admins add members and control who can see each site.

Join a team

If your team already uses ooda, join their team instead of creating a new one. Only a team admin can add you. The admin adds you from the Team page in the dashboard, in one of two ways:

  • Email invite. The admin enters your email address. You get an email with a link to create your account. Sign up with that same address. The invite expires after 7 days.
  • Join link. The admin shares a link. Anyone who opens it can join the team, so the admin can limit how many times it works or revoke it.

Several teams

One account can belong to several teams. To accept a pending email invite, open the Account page in the dashboard. You must verify your email address first. A join link works the same way: open it while you are signed in.

The CLI acts on one team at a time. Run ooda orgs to list your teams and ooda switch <org-id> to select one. To use another team for one command only, add --org <org-id> to publish, sites or secrets.

Waitlist invites

A waitlist invite creates a new team with you as its admin. If you want to join an existing team, do not use it. Ask that team's admin for an invite.