Operations

Deploy updates

Deploy only through the packaged CLI:

mimir deploy

The checked-in Wrangler configuration contains placeholder resource IDs and is not a supported production deployment path. The CLI materializes the embedded Worker and precompiled dashboard bundle, preserves owned configuration, applies D1 migrations, and deploys.

Deployment verification must use /whoami and direct session APIs. Do not call paid completion endpoints for a health check.

Diagnose a deployment

mimir doctor --json

Doctor is read-only. It validates managed artifacts, Worker API version/capabilities and bundle identity, active harness loads, Hermes plugin enablement, Hermes credentials, and compatibility routes. It also reports stale files next to the owned executable without deleting them. Use the exact repair it reports: connection failures use mimir login, stale Worker state uses mimir deploy, and missing or outdated managed artifacts use mimir install. See troubleshooting for activation and recovery states.

Update the CLI

mimir update --check
mimir update
mimir update --force

Release archives are verified against published checksums before replacement. The updater requires the receipt-owned executable, records the verified new hash, refreshes integrations, and guards rollback against concurrent binary replacement. On Windows, when the executable is locked by another Mimir process or an antivirus filter, the update is deferred: the verified binary is staged, pending-update.json is recorded, and a detached helper completes the swap once the lock clears. --force stops sibling Mimir processes and applies the update immediately.

Run mimir deploy separately when Doctor reports a stale Worker bundle or capability. Updating the CLI does not silently redeploy the Worker.

Managed ownership

Managed ownership lives in $MIMIR_HOME/install-receipt.json, defaulting to ~/.mimir/install-receipt.json. Operations append to $MIMIR_HOME/install-log.jsonl.

Mimir updates or removes only receipt-owned files whose bytes remain unchanged. Unknown, modified, missing, symlinked, and non-regular paths are preserved for review. General OpenCode configuration is never rewritten.

The receipt-owned binary is the command published to integrations. Ownership can be adopted only for the exact receipt target, a binary copied to the intended installation path, or a verified Mimir executable when the receipt has no owner. Invoking installation through another executable cannot silently transfer ownership.

Uninstall

mimir uninstall
mimir uninstall --keep-binary

Uninstall preserves the connection, machine token, materialized Worker, install log, and Cloudflare deployment. It removes only verified receipt-owned files whose current bytes still match the receipt.

Dashboard protection is documented separately under Dashboard Access.

Devices

Dashboard Settings lists registered devices and their current name, platform, last-seen time, observed harnesses, session count, and revocation state. Renaming changes only the display label; installation_id and historical session associations remain unchanged.

Revocation is irreversible in the dashboard. It disables every machine token and installation-scoped Hermes credential associated with that device, while retaining the device, sessions, and captured history for inspection. Setup and login do not reactivate the stable installation or its tokens; registration for that identity remains unusable and connection verification fails. To use the physical machine again, enroll it with a new installation identity. Dashboard renames remain available and change only the retained display label.