icp-cli 1.8.0 lets icp sync run without controller rights

DFINITY released icp-cli v1.8.0 on 30 October 2026. With this version, icp sync no longer needs controller rights, icp cycles buy behaves better in scripts, and a sandboxed extension system arrives as an experimental feature. If you upload assets to canisters you do not control, such as an SNS-owned frontend, or you run icp cycles buy in CI, upgrade now.

What changed in icp-cli 1.8.0

The main fix is in icp sync. Before uploading, it checks that each canister is running. Until now that check called canister_status, which, in the release's words, "only a controller or a listed status viewer may read". An identity that the canister merely authorizes was refused before anything was uploaded. The release notes give the example of a developer preparing an SNS-owned frontend for a commit proposal. In 1.8.0 the check uses a query probe instead, the same probe icp deploy already runs after it starts a canister. A stopped canister is still refused with the same advice, but only after the probe's "30-second wait", not at once.

If you want to know why canister_status is restricted in the first place, see our earlier piece on ICP's status visibility switch.

icp cycles buy, added in v1.7.0 for buying cycles with a card through CyclePay, gets four fixes:

CyclePay and Stripe are now named only when you use CyclePay's gateway. Any other gateway is called "the gateway".

The experimental part is extensions: third-party commands added to icp. An extension is a WebAssembly component that runs sandboxed. It has no filesystem, environment variables, sockets or processes. It can do only three things: make canister calls as the resolved identity on the resolved network, show a yes/no prompt, and show the user an http(s) URL to visit. On mainnet it may call only the canisters it declares. On other networks this allowlist is not enforced, so you can try an extension against a local network. Calls to the management canister are refused on every network.

Who is affected

• SNS and DAO frontend teams. If your identity is in a canister's asset permissions but not in its controller list, icp sync now works. Before, you needed a controller or a status viewer entry just to get past the pre-check.
• CI and agent scripts that buy cycles. A --json or -q run no longer waits for a prompt or fails for lack of a terminal. Stdout stays machine-readable.
• Scripts that parse errors. Gateway errors are now plain sentences, not IC0536 codes. If you match on the old error text, update your matching. Missing and negative amounts now both exit with status 2.
• Tool authors. Extensions give you a way to ship a command such as icp cyclepay without users granting it filesystem or network access. A built-in command always wins over an extension with the same name.

The extension design builds on the plugin-style direction we covered in ICP's developer workflow gets a modular command center.

What to do now

1. Install 1.8.0 with the release's installer script (macOS and Linux):

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/dfinity/icp-cli/releases/download/v1.8.0/icp-cli-installer.sh | sh

On Windows:

powershell -ExecutionPolicy Bypass -c "irm https://github.com/dfinity/icp-cli/releases/download/v1.8.0/icp-cli-installer.ps1 | iex"

Prebuilt archives with .sha256 checksums are also published for Apple Silicon and Intel macOS, x64 Windows, and ARM64 and x64 Linux.

2. If you added a controller or status viewer only so that icp sync would pass, re-run icp sync with the authorized identity. Then decide whether the extra permission is still needed.
3. In CI, remove workarounds such as piping yes into icp cycles buy. With 1.8.0, --json or -q is enough to skip confirmation.
4. Update any error matching that looked for IC0536 or clap's unknown-flag message. Check for exit status 2 on missing or negative amounts.
5. To try extensions, use the commands from the 1.8.0 release notes:

# install from an https URL or local path as `icp <NAME>`, pinned to a hash
icp extension install <NAME> <SOURCE> --sha256 <HASH>

# inspect and manage installed extensions
icp extension list --json
icp extension show <NAME> --json
icp extension uninstall <NAME>

Before asking for approval, install shows the extension, its sha256 and the mainnet canisters it will call, and it flags ledgers. --yes skips the prompt. The recorded sha256 is checked before every run. Installing under a name that is already installed replaces it. Because any name works, you can run a test build next to the stable one, for example cyclepay-beta beside cyclepay. Extension commands get help, parse errors and shell completion like built-in commands. Flags such as --identity and -e/-n are handled by icp itself before the extension runs.

For more depth, see our guide Motoko 2.0 tutorial: write and test your first canister.

Caveats

Extensions are listed under "Experimental" in the release notes, and the merged pull requests behind them (#839 and #840) are titled as a proof of concept. Expect changes. The canister allowlist applies only on mainnet. On a local network an extension can call any canister except the management canister, so test there with identities that hold nothing of value. Also note that with the new probe, icp sync against a stopped canister now takes about 30 seconds to fail.