Ship Capacitor updates with AI agents

Shipping an over-the-air update is four commands and about six things you have to remember. Which app. Which channel. Which runtime lane. Whether the web bundle still matches the native shell you shipped to the store. Whether auto-revert is on. What the current release even is, so you know what you are replacing.

None of that is hard. It is just easy to get wrong at 6pm on a Friday, and the failure mode is a broken app on every device that checks in.

So we taught coding agents to do the careful part. Ask Claude Code, Codex, or VS Code to ship an update and it reads your project, resolves the exact lane, checks compatibility, uploads the build — and then stops:

Publish  com.acme.shop
  lane       base · runtime 2026.04
  from       1.4.0  ->  1.5.0
  native     compatible (12 packages unchanged)
  immediate  no        auto-revert  on · 10% · min 100
Approve? This goes live for every device on that lane.

That block is the whole idea. Same shape every time, whether you asked in one sentence or walked through it step by step. You read five lines and say yes.

Getting it running

One command, from your project:

npx -y @otakit/cli@latest connect

It works out which client you use, signs you in if you are not already, and shows you the console, organization, project, and app it resolved — plus the exact file it is about to write — before it writes anything. --dry-run shows the same plan and touches nothing.

Claude Code has a plugin that ships the server and the release workflow together:

claude plugin marketplace add OtaKit/otakit
claude plugin install otakit@otakit

Then start with something read-only:

The parts we worried about

Handing release access to an agent is only reasonable if the boring safeguards are real. These are the ones that mattered to us.

Uploading is not publishing. They are separate tools. An agent can build, package, and upload a bundle for you to look at, and nothing about that reaches a device. “Upload this but don't release it” is a first-class thing to ask for.

A publish carries the state it reviewed. If a teammate releases between the agent showing you that block and you approving it, the publish is rejected rather than quietly overwriting their release. Retries are keyed, so a flaky connection cannot produce two releases.

Native changes stop it. OtaKit compares your dependencies against what the current release actually shipped. Add a native plugin and you need a store build, not an OTA update — the agent blocks and explains which packages changed. You can override that, but only deliberately, and the override is recorded.

It says when it doesn't know. If it cannot read your dependencies — wrong directory, dependencies not installed — it reports that it could not determine compatibility. It does not report “compatible” on the basis of having found nothing. That distinction took us longer to get right than it should have.

Rollout numbers are described honestly. Device telemetry is client-reported events, not users and not adoption. The agent is instructed to call them events, and to say “unavailable” rather than “zero” when analytics is not configured.

What it is actually good at

The obvious use is releasing, but the one that has surprised us is asking questions. “Why are people on 1.4.2 seeing rollbacks?” is a genuinely annoying thing to answer by hand — you are cross-referencing events, bundle versions, and lanes. An agent with read access does it in one turn.

• “Is this project set up correctly? Don't change anything.”
• “Upload 2.4.1 to staging but don't publish it.”
• “Prepare this for production with auto-revert on, then wait for me.”
• “Roll production back to the previous release.”

Clients that support MCP prompts get these as /check, /release, /rollout, and /revert.

It is the same release process

There is no agent-only path. An agent publishing to production produces exactly the release the dashboard would have, with the same lanes, the same force-immediate and auto-revert settings, and an audit entry naming who approved it. If you decide tomorrow that you would rather do it by hand, nothing about your releases changes.

The Skill that teaches all of this is a plain Markdown file. It is public in the repo — read it, disagree with it, fork it. It is the part of this that most deserves your scepticism, so we would rather you could see it.

The setup guide covers Claude Code, Codex, VS Code, connecting without a checkout, and self-hosted rollout.