there’s already so much bash scripts that i made 
uuuoohhhh
and dfx is so comfy and cozy 
is there any actual painkilling benefit in using icpcli?
2 Likes
icp-cli was intended to eventually replace dfx. (will be deprecated)
Everyone had time since October to move away from dfx.
As of March 6th, 2026 - v0.2.0 we are already on version 0.2
The docs are very good icp-cli Documentation | ICP CLI and the feedback thread is full of additional info and help.
nobody forces you to switch, but you need to keep in mind that dfx is a big monolith when it comes to managing versions along the toolchain.
this means that going forward you will be stuck at a specific version of:
- motoko compiler
- pocket-ic
- …
do you have a collection of scripts published somewhere which you would need to upgrade? I am curious what logic those scripts are handling for you.
did you try out using the icp-cli skill to migrate your scripts?
i’m actually bad with ai/agents
but i suppose i have to migrate asap so i dont get stuck like you said… will do it this weekend 
we’re happy to help if you run into issues
if you really want to do this manually I recommend to check following docs:
- Migrating from dfx | ICP CLI
- this also includes a guide how to migrate a wallet-canister to the proxy canister pattern
- CLI Reference | ICP CLI
please also note that we are going to update the Motoko recipe soon to rely on mops build for building canisters.
there are some work in progress PRs regarding this:
- feat: inject `_.canister.name` into recipe template context by marc0olo · Pull Request #567 · dfinity/icp-cli · GitHub
- feat!: rewrite Motoko recipe to delegate compilation to mops build by marc0olo · Pull Request #26 · dfinity/icp-cli-recipes · GitHub
- feat(motoko): migrate templates to @dfinity/motoko@v5.0.0 mops-build recipe by marc0olo · Pull Request #28 · dfinity/icp-cli-templates · GitHub
I have searched the docs for the icp-cli equivalent of dfx canister sign but I have not been able to find any equivalent or mention of why it was left out of icp-cli. Is this something that you have more insight on?
If it does eventually make its way to icp-cli, it would also be helpful to map the output to stdout instead of forcing the creation of a json file as output.
Hi @brady may I ask how you are using the dfx canister sign command?
I started a good while back on a project of what I call a “wallet interface” that is an open source browser extension that in one sense is similar to Plug in that it can spoof Plug as a provider but it passes you the command to execute in the terminal, making it compatible with air gapped setups.
Thanks to the wake of vibe coding I might be able to finally polish it up soon (it’s been on the back burner for years) especially since the developer community has exploded with growth in the wake of Caffeine AI **sarcasm intended**
dfx canister sign therefore is used to pass signed messages from a secure air gapped environment to the web browser environment. I find this setup to be more secure even than Oisy if handled properly and not to mention compatible with seed phrase.
That makes sense - we will add that shortly.
Although I’m leaning towards a flag on the icp canister call command instead of its own command like icp canister sign
Related to:
Can you expand on it please?
Do you mean that you like to do something like:
icp canister call <canister> <arg> --dump-request | icp canister call <canister> --in
No, I mean piping the command doesn’t seem to work at all, it always creates a json file as far as I can tell so I have to use rm message.json command often.
Yes, the command is wired to dump the content in message.json at the moment.
Is there something else you would want it to do?
Right now I am chaining commands like this:
dfx canister sign --network ic && cat message.json | gzip -c | base64 | qrencode -t ansiutf8 -m 1 -s 1 -l L && rm message.json
I personally would prefer to have a flag like --file - (I think the single dash argument is a standard convention) that the output would not create a json file but would go to the console’s stdout in other words, that it would be “pipable” and I won’t have to end my command chain with rm message.json … just my personal preference
is this first bioshock?
I never switched to icp-cli, i just used dfx only