Upgrading

Warden ships as a single binary with no runtime dependencies. Upgrading replaces the binary and restarts the daemon. Session state, rules, and Dream artifacts are preserved across upgrades.

Quick Upgrade

The fastest way to update:

warden update

This runs an interactive upgrade flow:

1. Checks the current installed version against the latest release
2. Shows a changelog summary for any new versions
3. Asks for confirmation before proceeding
4. Downloads and replaces the binary
5. Restarts the daemon automatically

If you want to skip the confirmation prompt (useful in scripts):

warden update --yes

Check Without Installing

To see whether an update is available without installing it:

warden update --check

This prints the current version, the latest available version, and the changelog summary. It makes no changes to the system. Exit code 0 means an update is available; exit code 1 means you are already on the latest version.

Install Method Detection

Warden detects how it was originally installed and uses the same method for updates:

If Warden cannot detect the install method (binary in an unexpected location), it falls back to direct download into ~/.warden/bin/.

Per-Method Upgrade Details

Direct Download

The default and most common method. Warden downloads the appropriate binary for your platform from GitHub releases, verifies the SHA-256 checksum, and replaces the existing binary atomically (write to temp file, then rename).

# Equivalent manual steps:
curl -L https://github.com/anthropics/warden/releases/latest/download/warden-$(uname -s)-$(uname -m) -o /tmp/warden-new
sha256sum --check /tmp/warden-new.sha256
mv /tmp/warden-new ~/.warden/bin/warden
chmod +x ~/.warden/bin/warden

Cargo Install

For Rust developers who installed via cargo install:

cargo install warden --force

The --force flag is necessary because cargo will otherwise skip the install if the version is already present. warden update adds this flag automatically.

Homebrew

brew upgrade warden

Homebrew manages the binary location and symlinks. After upgrading, verify:

which warden
warden version

Scoop (Windows)

scoop update warden

Scoop handles path management on Windows. The daemon service (if installed) is restarted automatically.

Post-Update Verification

After any upgrade, verify the installation:

warden version
warden daemon status
warden status

Expected output:

• warden version shows the new version number
• warden daemon status shows running with the new version (the daemon restarts automatically during warden update)
• warden status shows the current session state (or “no active session” if the daemon just restarted)

If the daemon version does not match the binary version, restart it explicitly:

warden daemon restart

Rollback

If an upgrade introduces a problem, you can roll back to the previous version. Warden keeps the previous binary as a backup:

warden update --rollback

This swaps the current binary with the backup and restarts the daemon. Only one level of rollback is supported — if you need to go back further, download a specific version from the releases page.

For direct-download installations, the backup is stored at ~/.warden/bin/warden.bak. For cargo installations, rollback reinstalls the previous version from crates.io:

cargo install warden --version <previous-version> --force

Version Compatibility

Warden maintains backward compatibility for session state and Dream artifacts across minor versions. A session started on v57 can be resumed on v58 without data loss.

Major version upgrades (e.g., v2.0) may include state migrations. The warden update command handles migrations automatically — it detects the old state format, converts it, and writes the new format. The old state files are backed up before migration.

Rule files are forward-compatible: rules written for an older version continue to work on newer versions. New rule features added in later versions are simply ignored by older versions.

Automated Upgrades

For teams that want to keep Warden current across all developer machines, consider adding a version check to your project’s setup script:

# In your project's setup.sh or Makefile:
REQUIRED_WARDEN="58"
CURRENT_WARDEN=$(warden version --short 2>/dev/null || echo "0")
if [ "$CURRENT_WARDEN" -lt "$REQUIRED_WARDEN" ]; then
    echo "Warden v${REQUIRED_WARDEN}+ required. Run: warden update"
    exit 1
fi

This ensures all team members are on a compatible version without forcing automatic upgrades.