Update & Service

Keep cmdop fresh. The daemon polls GitHub releases on a schedule (daily by default) and stages new binaries; you apply them with one command.

How auto-update works

Checker polls GitHub releases, writes ~/.cache/cmdop/update-cache.json.
Downloader fetches the staged binary to ~/.cache/cmdop/updates/cmdop-vX.Y.Z.
Updater atomically swaps the running binary (rename + copy) on cmdop update apply.
Restart chain (binary spawn → shell script → systemd-run) tries to bring the daemon back on the new binary.

Manual update


cmdop update             # check + apply (prompts before swap)
cmdop update check       # check only, no install
cmdop update apply       # apply a staged binary
cmdop update schedule    # configure auto-check interval and auto-apply

cmdop update schedule --interval 24h --auto-apply makes the daemon both check and apply without operator intervention. Use this on production servers behind a maintenance window.

Restart fallback chain

After binary swap, the daemon tries to restart in this order:

setsid (Unix) or DETACHED_PROCESS (Windows) — direct binary spawn
/bin/sh script that waits for the old PID, then execs the new binary
systemd-run --user --scope ... for restricted environments (Alibaba Cloud, etc.)

If all three fail, the binary swap still succeeded — just run cmdop restart manually.

On macOS under SIP, sudo cmdop update fails to re-exec because SIP blocks fork/exec from a sudo context. The CLI prints ErrMacOSRestartRequired. Run cmdop agent restart manually after the swap.

Cross-user cache split (Linux)

Symptom: sudo cmdop update apply after a normal cmdop update fails with “no pending update”.

Cause: ~/.cache resolves per-euid. Download as your normal user lands in /home/you/.cache; sudo reads /root/.cache (empty).

Fix: the CLI now walks all candidate cache dirs in resolvePendingUpdate(). Pre-emption: download as your normal user, only sudo for cmdop update apply if the target binary requires it (e.g., /usr/local/bin/cmdop owned by root).


cmdop update             # as you (download)
sudo cmdop update apply  # as root (write to /usr/local/bin)

OS service registration

Run the daemon as a system service so it survives reboot:


cmdop service install            # platform-detect (launchd / systemd / Windows)
cmdop service uninstall
cmdop service start
cmdop service stop
cmdop service restart
cmdop service status

Platform	Backend
macOS	LaunchAgent plist at `~/Library/LaunchAgents/com.cmdop.agent.plist`
Linux	systemd user service at `~/.config/systemd/user/cmdop.service`
Windows	Windows Service “CMDOP Agent”

See ./service for the standalone reference.

Mode (re-pointer)

Mode controls dev/prod scope. See ./agent § “Mode (dev vs prod)” or ./mode.


cmdop mode
cmdop mode toggle

Power blocker

On laptops, the daemon prevents system sleep by default — otherwise the relay drops mid-session. Disable with --no-power-blocker if you want the laptop to sleep normally:


cmdop agent start --no-power-blocker

Monitor & logs

Tail what the updater is doing:


cmdop logs -f
cmdop monitor

See ./logs and ./monitor.

Recommended production setup


# 1. Service install
cmdop service install
 
# 2. Schedule daily check + auto-apply
cmdop update schedule --interval 24h --auto-apply
 
# 3. Verify
cmdop service status
cmdop update check

Once configured, the daemon checks for updates every 24 hours, downloads, and atomically swaps without operator intervention. Tail cmdop logs -f if you want to watch.