OtaKitLet Claude Code ship your Capacitor updates, with an approval step
Set up Claude Code to check, upload and release Capacitor over-the-air updates through OtaKit. Two install commands, a real session from start to finish, and the safety checks that stop it from shipping something broken.
Claude Code already writes most of the fix. The part people still do by hand is the release: build, pick the right app and channel, check that the web bundle still matches the native app in the store, upload, publish, and then watch whether anything breaks. That is careful, repetitive work, and it is exactly where a tired human makes mistakes.
This guide connects Claude Code to OtaKit so it can do that work for a Capacitor app, while you keep the one decision that matters: approving the release.
What the agent can and cannot change. OtaKit ships the web layer of a Capacitor app (HTML, CSS, JavaScript, assets) over the air. Native code still goes through the App Store and Google Play. The agent checks this for you before every release.
1. Install (two commands)
The OtaKit plugin for Claude Code ships the MCP server and the OtaKit Agent Skill together:
npx -y @otakit/cli@latest login claude plugin marketplace add OtaKit/otakit claude plugin install otakit@otakit
Run /mcp in Claude Code and you should see otakit connected. If your app does not use OtaKit yet, add the plugin to the Capacitor app first and ship one store build; see setup.
2. Start read-only
A good first prompt changes nothing:
Check whether this project is ready to ship an OtaKit update. Don't upload anything.
Claude Code calls inspect_project. On our demo app the real result looks like this (trimmed):
Inspected the local Capacitor project. capacitorConfig appId 65bb56c1-… runtimeVersion demo-shell-v3 buildOutput out/ (exists) notifyAppReady found in app/page.tsx authenticated true findings none
It found the OtaKit config, the build folder and the notifyAppReady() call that makes automatic rollback work. If any of those were missing, it would say so here.
3. Ask it to ship
Build the app and ship it to the demo-agent channel with auto-revert on.
These are the steps it takes, with the real tool responses from that session:
| Step | Tool | What came back |
|---|---|---|
| Check native compatibility | check_compatibility | skipped, with a warning: no earlier release on this lane to compare against |
| Upload the bundle | upload_bundle | Uploaded bundle 1.0.0-agent.1 without publishing it (261 KB) |
| Prepare the release | prepare_release | Prepared the exact release state without changing it; next: review, then publish |
| Publish after your approval | publish_release | Published release 4e02b307-… |
| Read health | get_release_health | 0 events so far; auto-revert on (20% over at least 50 activations); analytics available |
Two details matter here. Uploading and publishing are separate, so an upload can never reach a device by itself. And the compatibility check is honest: on a brand-new lane there is nothing to compare against, so it reports skipped instead of pretending everything is fine.
4. The approval step
Before publishing, Claude Code shows the prepared release and waits. The OtaKit Skill instructs it to ask for approval, and publish_release is flagged as a destructive tool, so Claude Code asks for permission before running it. On a lane that already has a release, the block reads like this:
Publish com.acme.shop lane production · 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.
Read it line by line:
- lane: the channel and native runtime this goes to. A wrong channel is the most common release mistake.
- from → to: what users have now and what they will get.
- native: whether the web bundle still matches the native app. If you added a native plugin, this says so and the release stops.
- immediate: whether devices reload right away (for emergencies) or on the next launch.
- auto-revert: the rollback share and minimum sample that will pull the release automatically.
The publish carries the state you reviewed. If a teammate releases in between, yours is rejected instead of overwriting theirs.
5. Watch and roll back
After the release, ask in plain language:
- “How is the demo-agent release doing?”
- “Are people on 1.0.0-agent.1 seeing rollbacks?”
- “Roll production back to the previous release.”
Health numbers are events reported by devices, not users, and the tool tells Claude Code so. A revert goes through the same prepare-and-approve flow as a publish.
Where this fits
Native releases still go through the stores on your schedule. Everything in between, the copy fix, the broken button, the checkout bug, becomes a sentence to your agent and one approval. Setup for other agents (Codex, VS Code) is on the AI agents page, and every tool is documented in MCP & Agent Skills. For Codex specifically, see shipping Capacitor fixes from Codex.