Get the app

An approver is a device with its own Ed25519 key that wardend trusts after pairing: the Android app, the iPhone app, or wardenctl in a terminal on your laptop. The key stays on the device and never goes to the server. You need at least one approver; with two you can still approve when one is lost.

Android

The app is an Expo project in app/ of the repository. The build guide is app/docs/BUILD.md, section “Android: APK and AAB”: the preview profile gives an APK for all ABIs, production an AAB for Google Play. Builds run with eas build --local or fully locally, on macOS or Linux.

Install the APK on the phone, then connect it to wardend.

iPhone

The iOS app does what the Android app does. What works and what to set up in Apple Developer: iPhone app.

Build it on a Mac with app/docs/BUILD.md, section “iOS: TestFlight”: scripts/local/ios.sh builds the .ipa, scripts/local/ios.sh submit uploads it to your own App Store Connect, and the build appears in your TestFlight after processing (5 to 30 minutes). Push notifications for the phone need an APNs key on the server: Push notifications (APNs).

wardenctl on a laptop

wardenctl is the terminal counterpart of the app. It pairs with wardend over the same HTTP API and signs decisions with its own device key. Builds exist for macOS (arm64, amd64) and Linux (arm64, amd64).

Run it on a different machine from the agent’s, never on the agent’s host as the agent’s user: there the agent could read the device key or run wardenctl approve itself. wardenctl refuses to start next to an accessible wardend (exit code 3).

Get the binary on the laptop itself, not through the agent’s host:

• macOS: wardenctl_darwin_arm64.tar.gz or wardenctl_darwin_amd64.tar.gz from a daemon release;
• Linux: wardenctl inside wardend_linux_arm64.tar.gz or wardend_linux_amd64.tar.gz of the same release.

Check the archive against the release key with minisign before you unpack it: Verify releases. On a Mac remove the Gatekeeper quarantine only from a file whose signature checked out. The full guide: daemon/cmd/wardenctl/README.md.

Pair it with the link that wardend pair start prints (see Connect the phone):

wardenctl pair '<wardenclaw://pair?…>'

Then wardenctl pending, wardenctl show <id>, wardenctl approve <id>, wardenctl deny <id> or wardenctl watch. For scripts and test automation: External approvers and test automation.

Update the parts together

The app, wardend, wardenctl and the OpenClaw plugin speak one protocol, version 1 in the first release. The app checks the version of the server every time it connects. When they don’t match, the Connect tab says which side to update, with the raw error under Details:

• “The server is older than the app: update wardend on the server.” For the plugin: “The wardenclaw-gate plugin is older than the app: update the plugin on the OpenClaw gateway.”
• “The app is older than the server: update the app.”

While the versions don’t match, the app takes the cards of that server off the feed, signs nothing for it and tries again every 30 seconds. wardenctl checks the version too and exits with code 4 when it doesn’t match.

A request in a newer format than the app knows is not shown as a card. The feed shows a banner, “Requests this version cannot show: N”, with the note “The server sent requests in a newer format. Update the app to see them. Until then they cannot be allowed here and will expire on the server.” Such a request has no buttons, not even Deny: the app can’t check what it would sign. It expires on the server like any unanswered request, and the command is refused.

Next

Connect the phone: an address the device can reach, pairing and a check.