Skip to main content
Upgrade cordon to the latest version using the detected package manager.

Usage

cordon upgrade

Behavior

  1. Checks for the latest version via the update API (always performs a network call, even if CORDON_NO_UPDATE_CHECK is set).
  2. If already on the latest version, prints a message and exits.
  3. Detects the install method from the executable path:
    • Homebrew — binary under /opt/homebrew/, /usr/local/Cellar/, or /home/linuxbrew/.linuxbrew/
    • npm — binary under a node_modules directory or npm’s global prefix
    • Unknown — prints a link to the GitHub releases page and exits with an error
  4. Runs the appropriate upgrade command (brew upgrade cordon or npm install -g @codezero-io/cordon@latest).
  5. Verifies the upgraded binary reports the expected version.

Interactive prompt

You don’t need to run cordon upgrade explicitly. When a newer version is available and the session is interactive (stdin and stderr are terminals), most commands will prompt before running:
Update available: v0.3.0 (current: v0.2.0)

Upgrade now? [Y/n]
Accepting upgrades and re-executes the original command on the new binary. The prompt is skipped for upgrade, help, env, and status --quiet. In non-interactive sessions (piped input, CI, scripts), a one-line notice is printed to stderr with no prompt.

Running services

cordon upgrade replaces the binary on disk but does not restart running services. A launchd or systemd service continues executing the old binary in memory until restarted:
cordon upgrade
cordon service stop && cordon service start
If you use an integration that maintains persistent connections to cordon (Claude Code, Codex, Hermes), restart those sessions after restarting the service — they hold connections to the previous cordon process and will get stale-connection errors (typically TLS certificate failures) until reconnected.

Examples

# Upgrade to latest
cordon upgrade

# Non-interactive notice (no prompt)
cordon status | jq .
# stderr: Update available: v0.3.0 (current: v0.2.0)