Ship Capacitor fixes from Codex

Codex is good at finding and fixing the bug. With OtaKit connected, it can also ship the fix to your Capacitor app over the air, without a store build, and without taking the final decision away from you.

This guide covers setup, what Codex does on a release, and two setups for teams: read-only reporting and CI.

1. Setup

Install the OtaKit Agent Skill, sign in, and add the MCP server:

npx skills add https://github.com/OtaKit/otakit --skill otakit

npx -y @otakit/cli@latest login
codex mcp add otakit -- npx -y @otakit/cli@latest mcp

Or run npx -y @otakit/cli@latest connect in your project: it detects Codex, shows what it will configure, and asks before writing anything.

The Skill teaches Codex the release workflow (check, upload, prepare, approve, publish). The MCP server gives it the tools. Your Capacitor app needs the OtaKit plugin in a store build once; after that, web changes can ship over the air.

2. What Codex does when you ask it to ship

1. Inspects the project (inspect_project): OtaKit config, build folder, whether notifyAppReady() is called, sign-in state.
2. Checks native compatibility (check_compatibility): compares your native dependencies with what the current release shipped. A new native plugin means a store build, and Codex stops and says so.
3. Uploads the bundle (upload_bundle). This never publishes.
4. Prepares the release (prepare_release) and shows you the exact lane, the version change, the compatibility result and the auto-revert settings.
5. Publishes after you approve (publish_release). The publish carries the state you reviewed, so a release someone else made in between is never overwritten.

Codex asks before running tools according to its approval settings, and the OtaKit Skill tells it to stop for your approval before publishing. Keep publishing on manual approval; uploads and read-only checks are safe to allow.

3. Read-only reporting

Not everyone who asks “how is the release doing?” should be able to release. The remote endpoint uses OAuth scopes, so you can connect Codex with read access only:

codex mcp add otakit-remote --url https://console.otakit.app/mcp
codex mcp login --oauth-client-registration cimd \
  --scopes otakit:read,offline_access \
  otakit-remote

With only otakit:read, Codex can list releases, read health and summarize rollout events, but cannot upload, publish or revert. Revoke the connection any time from Settings → Agents in the dashboard.

4. In CI

For pipelines, use an organization key in OTAKIT_TOKEN (from your secret store, never a project file). The same CLI commands the agent uses work in any CI:

npm run build
npx -y @otakit/cli@latest upload --release staging

A common split: CI uploads every merge to staging, and a human (or Codex, with your approval) promotes to production. See CI automation.

5. After the release

Useful follow-up prompts:

• “How is the current staging release doing?”
• “List download errors for the last release.”
• “Prepare a revert of production and wait for me.”

Every write is attributed in the audit log, whether a person or an agent made it. For the same flow in Claude Code, see Claude Code for Capacitor releases; for all agents, the AI agents page.