Indeed, I had a messy .zshrc !
Thanks Raymond !
icp-cli v0.2.0 is here — friendly domains, canister migration, telemetry, and more
Hey everyone,
We’re excited to share that icp-cli v0.2.0 is now available! This release packs a ton of improvements to make your local development experience smoother, your canister management more powerful, and your workflow more transparent. Let’s dive in.
Highlights
Friendly Local Domains
Tired of copy-pasting canister principals to access your frontends locally? Now your canisters get human-readable domains out of the box — access frontend.local.localhost instead of <principal>.localhost.
Candid Interface Compatibility Checks
When upgrading a canister, icp-cli now automatically checks for Candid interface incompatibilities before deploying. Catch breaking changes before they hit your users.
Canister Logs
icp canister logs my-canister
icp canister logs my-canister --follow --interval 2
Stream canister logs right in your terminal. Use --follow to tail them continuously.
Canister Migration (Guide)
icp canister migrate-id my-canister
Move canister IDs across subnets — useful when reorganizing your infrastructure.
Flexible canister call Output Formats
icp canister call my-canister get_data --output candid
icp canister call my-canister get_data --output hex
icp canister call my-canister get_data --output text
Choose between auto, candid, text, and hex output modes.
Encrypted Identity Export
icp identity export my-identity --encrypt
Export identity PEM files without exposing raw keys in your terminal.
Local Caching for Recipes & Prebuilt Canisters
Recipes and prebuilt canister WASMs are now cached locally, so repeated builds and deploys don’t re-download everything.
Proxy Canister on Managed Networks
When starting a managed local network, a proxy canister is now automatically installed with all your identities as controllers. icp network status shows the proxy principal.
Bitcoin & Dogecoin Node Connectivity
Configure bitcoind-addr and dogecoind-addr in your managed network config to connect your local network to Bitcoin or Dogecoin nodes.
Subaccount Support
icp token, icp cycles, and icp identity account-id now support subaccounts and ICRC-1 account IDs.
Anonymous Usage Telemetry
We’ve added opt-out anonymous telemetry to help us understand which commands are used and where friction exists. It collects only command name, arguments, duration, and outcome — no personal data.
- Opt out anytime:
icp settings telemetry false,DO_NOT_TRACK=1, orICP_TELEMETRY_DISABLED=1 - Automatically disabled in CI environments
Autocontainerize
icp settings autocontainerize true
Networks can use pocket-ic directly, or a similar setup in a Docker container. With this setting, networks always get started as Docker containers.
Breaking Changes
- Recipe versions are now required. Recipes must be specified as
@registry/recipe@version— thelatestshorthand is no longer assumed. Update youricp.yamlaccordingly. - Argument type inference removed. Init/call args are now always assumed to be Candid. Use new parameters to specify other formats (hex, file paths).
- Minimum password length. New passwords for identity encryption must be at least 8 characters.
For the full list of changes, see the v0.2.0 release notes.
New Templates
We’ve expanded the icp-cli-templates repository with new starter templates:
- proxy — a ready-to-use proxy canister template for forwarding calls between canisters
- bitcoin-starter — get started building Bitcoin-integrated canisters on ICP
- static-website — a static website deployed to an asset canister
Spin them up with icp new my-project and select from the template list.
Migrated Examples
We’ve started migrating official examples in the dfinity/examples repository to support icp-cli alongside dfx. Most of these are designed to work with both tools, since ICP Ninja currently still relies on dfx. Check out the PRs if you’re curious about what dual-tool support looks like in practice:
IC Skills: Help Your AI Agent Use icp-cli
We’ve started working on IC Skills — and one of the first is the icp-cli skill. It teaches AI coding agents how to work with icp-cli, and we’re especially interested in how well it helps agents migrate projects from dfx to icp-cli.
We’d love your feedback — give it a try and let us know how it goes!
What’s Next
We’re continuing to improve the developer experience on ICP. Your feedback drives our roadmap — if you run into issues or have feature requests, please let us know here or open an issue on GitHub.
Happy building!
And I almost forgot, we have important new docs:
Are Canister Snapshots encrypted?
On chain, snapshots are stored next to the live canister states, so they are encrypted in the same way as any on-chain state. They are also protected by SEV on the corresponding subnets.
When you download a snapshots, you get a raw, unencrypted state that can be reuploaded or loaded into pocket-ic. So if you consider your canister state private, you should not share downloaded snapshots with others. Note that currently only controllers can download snapshots.
Whilst only Controllers can download snapshots, it’s concerning that these snapshots can be downloaded as raw, unencrypted images to a developer’s machine. Allowing this would expose organisations to significant regulatory risk - including breaches of GDPR (failure to apply appropriate technical measures such as encryption) and DORA (failure to implement required protective and resilience‑enhancing ICT controls).
In an institutional context, you wouldn’t want any single person having access as controller via icp-cli anyway. Even without snapshot download, you have to assume that controllers can extract any information that is on chain. They can after all make code changes.
But this is where projects like orbit come in, which can be configured to need multiple signatures to do any controller action. Institutional settings is exactly what it is designed for. You can also use a DAO like SNS, where you would need to vote on any controller operation, including code changes and taking snapshots. Not sure about orbit, but at least SNS doesn’t allow any snapshot downloads anyway, for exactly this reason.
icp-cli v0.2.2 is here — machine readable output and important fixes
Hey everyone,
We’re excited to share that icp-cli v0.2.2 is now available! It’s on npm already and will be on brew shortly.
Read below regarding important changes related to Internet Identity.
Highlights
Machine readable output
Many more commands support --json so you can pipe the output through tools like jq to use in your scripts, eg:
icp identity list --json | jq -r ".identities[].name"
Support for updated Internet Identity Canisters
Internet Identity has recently been split into a more traditional frontend and backend canister.
Starting with this latest version of the network launcher adding the ii option to your network will deploy both Internet Identity canisters and the frontend will be available by default at http://id.ai.localhost:8000
Starting with this version of the network launcher, the local internet identity will no longer be available at http://rdmx6-jaaaa-aaaaa-aaadq-cai.localhost - instead you will need to use the frontend canister http://uqzsh-gqaaa-aaaaq-qaada-cai.localhost or the mapped name http://id.ai.localhost.
The behavior for old network launchers remains unchanged.
To configure ii on your local network simply add the ii attribute to the network in icp.yaml like so:
networks:
- name: local
mode: managed
ii: true # Deploys the Internet Identity Cansiters
Coding with agents
We’ve released a set of skills for building on ICP, you can view them at https://skills.internetcomputer.org
Agents are increasingly capable, but often lack the context they need to do real work reliably. Skills give agents access to ICP specific context they can load on demand.
We’re keeping the skill up to date with the latest guidelines and recommendations. We encourage you to try them and provide feedback or PRs!
About ICP-CLI
I wanted to ask whether there are any plans to release something similar to what was done with the dfx tool for example, Vue.js templates with pre-implemented components such as Internet Identity.
I’m asking because I’ve been experimenting with the ICP-CLI for some time, and I’ve found that it can be quite challenging to use everything, since most things need to be set up manually and wiring the full project takes some time. I have the impression that dfx automatically generated many things. I also get the impression that working with dfx felt faster and more straightforward, so I was wondering if there are plans to improve the developer experience in a similar direction. That’s just my impression. I understand the tool is still new. Best regards.
Hi @KryL,
One of the fundamental problems with dfx is that it did too many things, specially for motoko. It acted as the build orchestrator and the project management tool. So the version of dfx you were using pinned you to a version of the motoko compiler and the asset asset canister.
icp-cli decouples the project management from the builds and delegates the builds to language specific tooling. This allows you to upgrade icp-cli independently from the language toolchains and from the asset canister version you want to use.
The downside is that there are some things you have to be more explicit about:
- How and when you generate bindings
- Where the did file comes from
Could you give me some examples of specific things you’re having trouble with or that you felt were better in dfx?
Hi @KryL, I think this is a very valid point.
For the frontend wiring part, one option today is ic-reactor. It can remove a lot of the manual canister/frontend setup by generating typed clients from your .did files.
For Vue or vanilla TypeScript, you can use the non-React target:
pnpm add @ic-reactor/core @tanstack/query-core @icp-sdk/core
pnpm add -D @ic-reactor/vite-plugin
Then in vite.config.ts:
import { defineConfig } from "vite"
import vue from "@vitejs/plugin-vue"
import { icReactor } from "@ic-reactor/vite-plugin"
export default defineConfig({
plugins: [
vue(),
icReactor({
target: "core",
canisters: [
{ name: "backend", didFile: "./backend/backend.did" },
],
}),
],
})
Create a shared client:
// src/clients.ts
import { ClientManager } from "@ic-reactor/core"
import { QueryClient } from "@tanstack/query-core"
export const queryClient = new QueryClient()
export const clientManager = new ClientManager({
queryClient,
withCanisterEnv: true,
})
Then you can call the generated typed reactor from Vue, Pinia, or plain TypeScript:
import { backendReactor } from "./declarations/backend"
const greeting = await backendReactor.callMethod({
functionName: "greet",
args: ["World"],
})
Internet Identity can also be handled through the same ClientManager:
await clientManager.login()
const principal = await clientManager.getUserPrincipal()
await clientManager.logout()
Docs:
- Vite plugin: @ic-reactor/vite-plugin | IC Reactor
- CLI codegen: @ic-reactor/cli | IC Reactor
- Vanilla TypeScript example: TypeScript Demo | IC Reactor
So I agree that icp-cli should probably stay less opinionated than dfx, but templates can still help a lot. A Vue template with icp-cli + Vite + Internet Identity + generated typed canister clients would probably remove most of the manual setup friction.
I just want to note that anybody can create their own templates, contribute to existing templates or propose new official templates:
Ok thank you very much for the suggestions and solutions. I’ll try to put it all together.
Hey guys, i installed skills.
I picked CONTINUE, but skills where never added to it because it does not use skills folder, it uses rules folder.
So, dfx is not used anymore? its now icp-cli, AI agents are so confused.
which (coding) agent are you using and how did you install the skills? would be good to get more information about what steps you have taken and what the concrete issue was.
So, dfx is not used anymore? its now icp-cli, AI agents are so confused.
yes, but that’s exactly one reason why skills are helpful. they guide coding agents to use the correct and latest patterns.
Visual Studio Code+Ollama+Continue extention+Gemma4:e4b and quen3 coder.
npx skills add dfinity/icskills
Added all skills, picked Continue, after finished, it added files .continue\skills but correct is .continue\rules
Honestly, i made 1 skill myself, than AI generated code and folders/files, correct structure. After icp-cli + Dfinity skills, my AI broke down, it seems like cant read skills, dont know new structure and in some reason cant make files anymore. Before accept and made files to folder, i dont know if something is broken on my side or what is going on.
What you could do is test local free AI, paid ones most likely work fine (Cursor, Claude) as they know code well.
we cannot control what the skills cli is doing and I haven’t used Continue before. maybe it is worth creating an issue in GitHub - vercel-labs/skills: The open agent skills tool - npx skills · GitHub if the skills are installed in the wrong location.
for simplicity, we currently recommend to just use following prompt when working with your agent:
Fetch https://skills.internetcomputer.org/llms.txt and follow its instructions when building on ICP
you can also just include exactly this instruction in your project repo as main instruction for your agent. I am curious if your agent will be doing the right things if you test this in a new project and new session without prior context.
bottom line is that you don’t need the skill files locally in your repo. but in any case you should know how to point your agent to the correct instructions.
e.g. Claude always preferred CLAUDE.md whereas most agents lookup AGENTS.md (not sure if this is still the case to be honest). so what you can do in such a case is maintain the core project instructions in AGENTS.md and then just create a symlink for CLAUDE.md pointing to it.
Just a question, but why all of this has to be so hard to set up.
Very first time i tested with dfx (2 years ago?), on windows it was impossible. On linux i remember i did run into other problems.
Now on windows when trying to set up, cli, i take test hello world, try to deploy locally, i get error windows not supported, use wsl.
icp new my-project
icp new my-project --subfolder hello-world
–define backend_type=motoko
–define frontend_type=react
–define network_type=Default
cd my-project
icp network start -d
icp network status
icp deploy
I dont ever reach to deploying locally, i wonder how many new people have run into same problem and just quit.
Ollama + qwen3 are pretty impossible too, as qwen has no internet access, cant use skills at all by searching what needed. Can feed by pasting them, but than looks like it still cant manage entire table as it has to get skills from multible locations.
So my question is why it all has not made simple. If i would be founders of chain, i would make single program that people can download. Basically automated as much as can, build manually or connect LLMs by api or use local Ollama and agent will generate all needed files we need, test with 1 click. I see this only way to bring in lot of people, currently its like building is kept for those who know how to code or who has time to learn. But most just want to build few things, thats it. Caffeine is perfect for it, but there we DONT own built apps and no idea what for we are charged.
Hey @Henn91, can you post some logs of the errors you are seeing?