Updating from the network
plugin outdated is the polling verb of the daily loop. It re-fetches every
registered marketplace into the local cache and recomputes version pins — without
touching any agent config. apply then renders from that cache, so it’s always
fast, offline, and reproducible.
agentsync plugin outdated # refresh cache + show pending bumpsagentsync plugin upgrade --all # re-pin every pending bump, then re-applyagentsync plugin upgrade --all --lossless # same, skipping bumps that would lose translationagentsync plugin upgrade atlassian # re-fetch one plugin, then re-applyBoth upgrade forms end in a re-apply, so an upgrade reaches your agents in one
command instead of leaving them stale until the next apply.
plugin outdated is not a pure read, despite the npm outdated prior: it
uses the network and writes state (each marketplace’s fetch timestamp and head
SHA). It is also not the only networked command — plugin add, plugin upgrade, marketplace add, import <agent>:plugin, and init <git-url> all
fetch. It is simply the one the daily loop runs.
Why the split matters
Section titled “Why the split matters”flowchart LR
NET["marketplaces<br/>+ npm registry"] -->|"plugin outdated (network)"| CACHE[".state/cache/"]
CACHE -->|"apply (offline)"| AGENTS["agent configs"]
Separating “fetch” from “render” means:
applyis deterministic — same cache in, same config out, no surprise network changes mid-apply.applyworks offline — on a plane, in a locked-down CI runner, anywhere.- Upgrades are intentional — you see pending plugin bumps from
plugin outdatedbefore they take effect.
Scheduling refreshes
Section titled “Scheduling refreshes”agentsync ships no daemon. Want nightly refreshes? Wire the one-liner into your own scheduler:
agentsync plugin upgrade --all --lossless| Platform | Mechanism |
|---|---|
| macOS | launchd agent |
| Linux | cron or a systemd timer |
| Windows | Task Scheduler |