# Icp-cli announcements and feedback discussion

**URL:** <https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410>\
**Category:** Developers\
**Tags:** dfx\
**Created:** [November 24, 2025, 9:24pm UTC](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410 "2025-11-24T21:24:35Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![raymondk](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/raymondk/32/6174_2.png) [@raymondk](https://forum.dfinity.org/u/raymondk)\
**Post date:** [November 24, 2025, 9:24pm UTC](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/1 "2025-11-24T21:24:35Z")

</div>

Hey folks, this thread will aggregate all icp-cli related announcements.

Take a look at:

- The docs: [https://cli.internetcomputer.org](https://cli.internetcomputer.org)
- The examples: [icp-cli/examples at main · dfinity/icp-cli · GitHub](https://github.com/dfinity/icp-cli/tree/main/examples)
- The templates: [GitHub - dfinity/icp-cli-templates: Templates for creating new icp-cli projects · GitHub](https://github.com/dfinity/icp-cli-templates)

Your feedback is welcome and your contributions even more, specially as far as clarifying docs and examples.

## Release announcements

**June 20th, 2026** - [v1.0.0](https://github.com/dfinity/icp-cli/releases/tag/v1.0.0)

> [@Icp-cli announcements and feedback discussion](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/103):
>
> icp-cli v1.0.0 is released Hi folks, It’s been out for a few days already, but I’m happy to announce that [icp-cli v1](https://github.com/dfinity/icp-cli/releases/tag/v1.0.0) is released. [Agent skills](https://skills.internetcomputer.org) and [icp-cli docs](https://cli.internetcomputer.org/1.0/) have been updated. Highlights For those of you who have been keeping up with icp-cli releases, you’ll find there are no big changes changes since v0.3.x and that’s exactly this point. icp-cli is now decoupled from: The canister build toolchains The asset canister sync process The local network launcher We feel confident that we’ve …

**June 5th, 2026** - [v0.3.0](https://github.com/dfinity/icp-cli/releases/tag/v0.3.0)

> [@Icp-cli announcements and feedback discussion](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/96):
>
> icp-cli v0.3.0 is released Hi folks, I’m excited to announce that [icp-cli v0.3.0](https://github.com/dfinity/icp-cli/releases/tag/v0.3.0) is released. As usual, it’s on npm already and will be available on homebrew soon. We’re planning for this to be the last 0.x release before an official v1.0 next week. Read on for important information. [Agent skills](https://skills.internetcomputer.org) and [icp-cli docs](https://cli.internetcomputer.org/0.3/) have been updated. Highlights warning Breaking change to asset syncing First a reminder that it’s been our goal for icp-cli to decouple to the cli tool from the build toolchains, …

**March 28th, 2026** - [v0.2.2](https://github.com/dfinity/icp-cli/releases/tag/v0.2.2)

> [@Icp-cli announcements and feedback discussion](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/68):
>
> 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](https://github.com/dfinity/icp-cli/releases/tag/v0.2.2) is now available! It’s on [npm](https://www.npmjs.com/package/@icp-sdk/icp-cli) already and will be on [brew](https://github.com/Homebrew/homebrew-core/pull/274665) shortly. warning 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 Int…

**March 6th, 2026** - [v0.2.0](https://github.com/dfinity/icp-cli/releases/tag/v0.2.0)

> [@Icp-cli announcements and feedback discussion](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/62):
>
> 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](https://github.com/dfinity/icp-cli/releases/tag/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 …

**February 12th, 2026** - icp-cli Walkthrough (Meeting announcement)

> [@Icp-cli announcements and feedback discussion](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/34):
>
> icp-cli Walkthrough: Templates, Recipes, and Dev Q&A Hi everyone, The icp-cli is now out of beta and ready for prime time. To ensure everyone is up to speed with the new command-line experience, we’re hosting a casual, terminal-first hangout session on February 19th. This isn’t a marketing presentation. We’re skipping the slides to focus on the actual developer workflow. What we’ll cover: Initial Setup: A grounded look at the icp command structure and how to get running. Templates & Recipes…

**February 4th, 2026** - [v0.1.0](https://github.com/dfinity/icp-cli/releases/tag/v0.1.0) (first official release)

> [@Icp-cli announcements and feedback discussion](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/27):
>
> Introducing icp-cli v0.1.0 - The First Official Release We are thrilled to announce the first official release of icp-cli - a modern, fast, and developer-friendly command-line tool for building and deploying applications on the Internet Computer. After months of beta testing and invaluable community feedback, icp-cli v0.1.0 is here with powerful new features and the easiest installation experience yet! Quick Install via npm Getting started is now as simple as: npm install -g @icp-sdk/icp-cli …

**January 28th, 2026** - [v0.1.0-beta.5](https://github.com/dfinity/icp-cli/releases/tag/v0.1.0-beta.5) (latest) / [v0.1.0-beta.4](https://github.com/dfinity/icp-cli/releases/tag/v0.1.0-beta.4)

> [@Icp-cli announcements and feedback discussion](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/24):
>
> icp-cli v0.1.0-beta.5 Released We’re excited to announce the release of icp-cli v0.1.0-beta.5 with several important improvements for ICP developers. Highlights since beta.3 Windows Support icp-cli now runs natively on Windows, expanding our platform coverage to macOS, Linux, and Windows. See it in action: [icp-cli setup and demo (Windows) - asciinema.org](https://asciinema.org/a/773891) Windows limitations: Local networks require [Docker Desktop](https://docs.docker.com/desktop/setup/install/windows-install/) Motoko canisters require [WSL](https://learn.microsoft.com/en-us/windows/wsl/install) — the Motoko compiler doesn’t run natively on Win…

**January 15th, 2026** - [v0.1.0-beta.3](https://github.com/dfinity/icp-cli/releases/tag/v0.1.0-beta.3)

> [@Icp-cli announcements and feedback discussion](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/11):
>
> Hey folks, we’re excited to share that [v0.1.0-beta.3](https://github.com/dfinity/icp-cli/releases/tag/v0.1.0-beta.3) of the icp-cli is now live! rocket This release brings several improvements to the developer experience. My personal highlight? Interactive call argument building with candid assist. It makes crafting canister calls significantly faster and less error-prone. television See it in Action@raymondk recorded a great demo showcasing the latest features, including the new interactive flow: backhand_index_pointing_right [Watch the Asciinema D…](https://asciinema.org/a/768008)

**December 12th, 2025** - [v0.1.0-beta.1](https://github.com/dfinity/icp-cli/releases/tag/v0.1.0-beta.1)

> [@Icp-cli announcements and feedback discussion](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/5):
>
> Hi folks, there’s an updated [beta release v0.1.0-beta.1](https://github.com/dfinity/icp-cli/releases/tag/v0.1.0-beta.1) that introduces some new features: You can create project from templates. DFINITY has a small set of templates that the tool uses by default, but you can also point it to your own template repository. See: [GitHub - dfinity/icp-cli-templates: Templates for creating new icp-cli projects](https://github.com/dfinity/icp-cli-templates) We introduced a new local network launcher. It is meant to keep a stable interface even as new versions of the replica are released. This means the cli tool…

**November 24th, 2025** - [v0.1.0-beta.0](https://github.com/dfinity/icp-cli/releases/tag/v0.1.0-beta.0) (first announcement)

Hello everyone, the first beta release of icp-cli is available here: [Release Release v0.1.0-beta.0 · dfinity/icp-cli · GitHub](https://github.com/dfinity/icp-cli/releases/tag/v0.1.0-beta.0)

---

<div class="post-metadata">

**Author:** ![Gwojda](https://avatars.discourse-cdn.com/v4/letter/g/5fc32e/32.png) [@Gwojda](https://forum.dfinity.org/u/Gwojda)\
**Post date:** [November 25, 2025, 10:00am UTC](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/2 "2025-11-25T10:00:47Z")

</div>

Hey,  
I didnt fully checked doc yet, but can you share what’s the difference with DFX ?  
Thanks !

---

<div class="post-metadata">

**Author:** ![tiago89](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/tiago89/32/22332_2.png) [@tiago89](https://forum.dfinity.org/u/tiago89)\
**Post date:** [November 25, 2025, 10:27am UTC](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/3 "2025-11-25T10:27:30Z")

</div>

Interesting improvements 👍

Only checked the docs, but this .yaml config is sick! Big congrats 👏

Allowing for cli to sync canisters at this level of precision is very interesting for professional developers that are optimizing and working on a team.

Think it’s a significant and worthwhile improvement. Keep it up!

If I catch any improvs / bugs will open an issue 👍

---

<div class="post-metadata">

**Author:** ![raymondk](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/raymondk/32/6174_2.png) [@raymondk](https://forum.dfinity.org/u/raymondk)\
**Post date:** [November 25, 2025, 12:52pm UTC](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/4 "2025-11-25T12:52:43Z")

</div>

The important features are:

- Decoupling the cli tool from the toolchains used to build the canisters - for eg updating your cli doesn’t necessarily force you to update your motoko version, you can do that when you are ready.
- “Recipes” allow you to share build patterns within your team or with the community instead of the common build patterns being hard coded into the cli itself. You can write your own or used the ones [published by the foundation](https://github.com/dfinity/icp-cli-recipes/).
- There is a concept of “environment” which is a logical set of canisters on a network. So you are able to deploy the same canisters to different environments and manage their settings independently.
- You can build the canisters once and deploy the same compiled code to different environments - canister ids don’t need to be hard coded into your canister code instead the cli automatically injects canister environment variables at deployment time so that ids: “Build once, deploy many times”

---

<div class="post-metadata">

**Author:** ![raymondk](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/raymondk/32/6174_2.png) [@raymondk](https://forum.dfinity.org/u/raymondk)\
**Post date:** [December 12, 2025, 2:54am UTC](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/5 "2025-12-12T02:54:57Z")

</div>

Hi folks, there’s an updated [beta release v0.1.0-beta.1](https://github.com/dfinity/icp-cli/releases/tag/v0.1.0-beta.1) that introduces some new features:

- You can create project from templates. DFINITY has a small set of templates that the tool uses by default, but you can also point it to your own template repository. See: [GitHub - dfinity/icp-cli-templates: Templates for creating new icp-cli projects](https://github.com/dfinity/icp-cli-templates)
- We introduced a new local network launcher. It is meant to keep a stable interface even as new versions of the replica are released. This means the cli tool will work with different versions of the network: [GitHub - dfinity/icp-cli-network-launcher: Simplified CLI interface to pocket-ic setup](https://github.com/dfinity/icp-cli-network-launcher)

For now, you can install manually or for those of you on mac os you can install it with an experimental homebrew tap:

```auto
brew tap raymondk/icp-cli
brew install icp-cli

```

To see the new cli in action, check out this video: [icp-cli with brew install - asciinema.org](https://asciinema.org/a/phzr4RaWCsQfPN82IG8MrYUMh)

What we’re working on next:

- Native support for docker based networks:
  - This allows developers to easily use complex network setups for local development and share them across teams.
  - Will allow us to release a windows native version of the cli

- Make the CLI installable through common package managers

As always, if you have feedback, we’re happy to hear it.

---

<div class="post-metadata">

**Author:** ![b3hr4d](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/b3hr4d/32/9755_2.png) [@b3hr4d](https://forum.dfinity.org/u/b3hr4d)\
**Post date:** [January 8, 2026, 2:05pm UTC](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/6 "2026-01-08T14:05:03Z")

</div>

I’ve been playing around with the new `icp-cli` and I have to say, the work you’ve done is fantastic. The tool feels incredibly well-architected and the recipe-based approach is a huge step forward for modularity in the ecosystem—it’s refreshing to see such a clean and intuitive interface.

As I’m exploring the recipe system, I have a specific use case I’d love to get your thoughts on. I’m the author of [ic-reactor](https://github.com/B3Pay/ic-reactor), a library for React integration and state management. I’m interested in creating a recipe that helps users automate their frontend setup by generating the necessary “reactor” configuration files (like `.ts` or `.js` configs) based on the canister’s build artifacts.

From what I’ve seen in the `dfinity/icp-cli-recipes` repo, the current flow is very focused on preparing the WASM through `build` steps. My question is: **Is there a recommended pattern for recipes to perform “side-effect” actions like generating local project files?**

Specifically, once a backend canister is built and its Candid interface or Canister ID is resolved, I’d like to trigger a script that writes a configuration file back into the project’s source tree.

1. Is this something that should live within a `build` step, or is it better suited for a different part of the manifest?
2. Do you envision recipes being able to interact with the local filesystem to “scaffold” or update configs as part of the standard workflow?

I’d love to hear the team’s vision for this, as it would be a game-changer for library authors looking to provide “zero-config” setups for their users.

---

<div class="post-metadata">

**Author:** ![Vivienne](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/vivienne/32/29170_2.png) [@Vivienne](https://forum.dfinity.org/u/Vivienne)\
**Post date:** [January 8, 2026, 2:35pm UTC](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/7 "2026-01-08T14:35:39Z")

</div>

Thank you so much for the kind words!

> [@b3hr4d](#):
>
> the current flow is very focused on preparing the WASM through `build` steps.

Yes, currently we force the output of every recipe to be a wasm. I think the closest thing to your situation that we already have is the [asset canister recipe](https://github.com/dfinity/icp-cli-recipes/blob/main/recipes/asset-canister/recipe.hbs). Is ic-reactor very agnostic to other parts of the build? Then the current setup likely does not work well for you.

Partially speculating since I’m not that great at frontend: Could it be that icp-cli is the wrong place to hook into? It could be that creating a bundler plugin (is that what it’s even called? 😅 I’m talking about vite or webpack stuff here…) that is ‘only’ part of the frontend build may work better in this case since you seem to be very tied to react with your tooling.

> [@b3hr4d](#):
>
> once a backend canister is built and its Candid interface or Canister ID is resolved, I’d like to trigger a script that writes a configuration file back into the project’s source tree

We are moving towards not hard-coding canister ids. We are explicitly not requiring canister ids to be known at build time so that builds are no longer network dependent. Our asset canister serves canister ids in cookies that are returned with html files now and we plan to use that mode of canister id injection moving forward.

I’ll bring your points up with the team, thanks a lot for your input! Hopefully I’ll be able to provide some more concrete answers afterwards

---

<div class="post-metadata">

**Author:** ![b3hr4d](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/b3hr4d/32/9755_2.png) [@b3hr4d](https://forum.dfinity.org/u/b3hr4d)\
**Post date:** [January 8, 2026, 3:10pm UTC](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/8 "2026-01-08T15:10:43Z")

</div>

Hi Vivienne,

Thank you for the thoughtful response! That context is incredibly helpful, especially the shift toward runtime canister ID injection via cookies—I fully support moving away from the brittle experience of managing `.env` files and hard-coded IDs.

Regarding the “side-effects” and the CLI’s role, I’ve been looking into the [`@icp-sdk/bindgen`](https://js.icp.build/bindgen/latest/) library used in your examples. I noticed that instead of a `dfx generate`-style command, the `icp-cli` ecosystem seems to favor a Vite plugin (from `@icp-sdk/bindgen/plugins/vite`) to handle the Candid-to-TypeScript generation.

This seems to confirm your point that the bundler is the right place to hook in. I could certainly architect **ic-reactor** to follow this exact pattern:

1. **A Bundler Plugin:** Instead of the CLI generating the “reactor” config, I can provide a Vite/Webpack plugin that monitors the Candid artifacts produced by the `icp-cli` build.
2. **Runtime IDs:** Since you mentioned the asset canister will serve IDs via cookies, I can update the `ic-reactor` core to automatically look for these credentials at runtime, making the generated config files even simpler and truly “network agnostic.”

**Two quick follow-up questions for the team:**

- **Standardized Artifact Discovery:** For bundler plugins to work seamlessly, is there a recommended standard path where `icp-cli` will consistently output `.did` files for backend canisters? In the examples, I see them in `../../backend/dist/`, but knowing if this will be a stable convention would help me build a “zero-config” plugin.
- **Recipe Output Types:** If a recipe is strictly “frontend-tooling” (like a reactor generator), would you ever consider a “Metadata” or “Config” output type for recipes, or is the intention to keep the CLI’s recipe engine purely for WASM/Canister logic?

I’m really excited about the cookie-based ID injection—that alone solves 90% of the friction library authors face!

---

<div class="post-metadata">

**Author:** ![b3hr4d](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/b3hr4d/32/9755_2.png) [@b3hr4d](https://forum.dfinity.org/u/b3hr4d)\
**Post date:** [January 9, 2026, 6:31pm UTC](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/9 "2026-01-09T18:31:59Z")

</div>

Thanks @raymondk for the call today—really helpful!

I’ve been building `@ic-reactor/cli`, which generates React hooks from Candid interfaces (using `@icp-sdk/bindgen` under the hood). Here’s what users end up with:

**Config (`reactor.config.json`):**

```json
{
  "outDir": "src/canisters",
  "canisters": {
    "counter": {
      "didFile": "./backend/counter.did",
      "network": "local"
    },
    "ledger": {
      "didFile": "./candid/ledger.did", 
      "canisterId": "ryjl3-tyaaa-aaaaa-aaaba-cai"
    }
  },
  "generatedHooks": {
    "counter": ["get_count", "increment"],
    "ledger": ["icrc1_balance_of", "icrc1_decimals", "icrc1_name", "icrc1_transfer"]
  }
}

```

- **Local canisters** (`counter`): ID resolved from environment at runtime
- **Mainnet canisters** (`ledger`): Hardcoded `canisterId` for production

**Generated files:**

```auto
src/canisters/
├── counter/
│ ├── declarations/counter.did.ts
│ ├── reactor.ts
│ └── hooks/
│ ├── getCountQuery.ts
│ └── incrementMutation.ts
└── ledger/
    └── hooks/...

```

* * *

**Integration idea via [icp-cli-recipes](https://github.com/dfinity/icp-cli-recipes):**

Could we create a recipe that runs `@ic-reactor/cli sync` after the backend canister is built/deployed? Something like:

```yaml
# ic-reactor-sync recipe
name: ic-reactor-sync
triggers:
  - after:build
  - after:deploy
run: npx @ic-reactor/cli sync

```

This would auto-regenerate hooks whenever the Candid interface changes, without needing a separate watch process.

**What would help:**

1. **Recipe triggers for “candid updated”** - So we can sync hooks automatically
2. **Access to canister metadata in recipes** - `.did` paths, canister IDs, network

Would love to contribute a recipe to the [icp-cli-recipes](https://github.com/dfinity/icp-cli-recipes) repo if this fits the vision! 🙌

---

<div class="post-metadata">

**Author:** ![raymondk](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/raymondk/32/6174_2.png) [@raymondk](https://forum.dfinity.org/u/raymondk)\
**Post date:** [January 13, 2026, 1:08am UTC](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/10 "2026-01-13T01:08:24Z")

</div>

Hi @b3hr4d,

The recipes are meant to be translated into `build` and `sync` steps.  
`build` will produce the wasm and possibly some assets to be synched after the wasm is updated in the canister.

In this case, if the bindings are not generated, the build is likely to fail. I assume in your examples that you need to have the `counter.did.ts` and the `hooks/*.ts` files in order for code to compile.

What you might want to do is create a recipe that will run the binding generation and the compilation+bundling

```auto
# yaml-language-server: $schema=https://github.com/dfinity/icp-cli/raw/refs/tags/v0.1.0-beta.2/docs/schemas/canister-yaml-schema.json

name: my-frontend-canister

build:
  steps:
    - type: pre-built
      url: https://github.com/dfinity/sdk/raw/89243f2268b6d0ec77d589b7b1b27af931f70edd/src/distributed/assetstorage.wasm.gz
      sha256: b312a16c3179cf8384afa852e468c1333b7439d4c5a39f26df69b12320f629f8

    - type: script
      command: npm ci

      # Generate the bindings
    - type: script
      command: npx @ic-reactor/cli sync

    - type: script
      command: npm run build

sync:
  steps:
    - type: assets
      dirs:
        - app/dist

```

Let me know if that makes sense.

Also, if you want to create a recipe, I would suggest you create it in your own repo. You could release it from the same repository. In the `type` field of a recipe you can use a url that points to your `.hbs` template.

```auto
# an example of a template
 curl -L https://github.com/dfinity/icp-cli-recipes/releases/download/rust-latest/recipe.hbs

```

---

<div class="post-metadata">

**Author:** ![marc0olo](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/marc0olo/32/17290_2.png) [@marc0olo](https://forum.dfinity.org/u/marc0olo)\
**Post date:** [January 15, 2026, 8:41am UTC](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/11 "2026-01-15T08:41:19Z")

</div>

Hey folks,

we’re excited to share that **[v0.1.0-beta.3](https://github.com/dfinity/icp-cli/releases/tag/v0.1.0-beta.3)** of the `icp-cli` is now live! 🚀

This release brings several improvements to the developer experience. My personal highlight? **Interactive call argument building with candid assist.** It makes crafting canister calls significantly faster and less error-prone.

#### 📺 See it in Action

@raymondk recorded a great demo showcasing the latest features, including the new interactive flow: 👉 **[Watch the Asciinema Demo](https://asciinema.org/a/768008)**

**What’s covered in the video:**

- Installing via the **brew tap**.
- Creating a new project from a **template**.
- Deploying to both **local** and **dockerized** networks.
- Making canister calls using the new **Candid assist**.

#### 🛠 Installation & Updates

For a full breakdown of changes, including bug fixes and minor improvements, **[check out the full Release Notes here](https://github.com/dfinity/icp-cli/releases/tag/v0.1.0-beta.3)**.

You can grab the latest version using Homebrew or the standalone installer:

- **Via Homebrew** :

```auto
brew install dfinity/tap/icp-cli

```

- **Via Shell Script Installer:**

```auto
curl --proto '=https' --tlsv1.2 -LsSf https://github.com/dfinity/icp-cli/releases/download/v0.1.0-beta.3/icp-cli-installer.sh | sh

```

#### 💬 We want your feedback!

Please give it a spin and let us know what you think. If you have detailed suggestions or feedback you’d like to discuss in person, please reach out - we’re happy to jump on a call!

---

<div class="post-metadata">

**Author:** ![b3hr4d](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/b3hr4d/32/9755_2.png) [@b3hr4d](https://forum.dfinity.org/u/b3hr4d)\
**Post date:** [January 15, 2026, 8:49am UTC](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/12 "2026-01-15T08:49:12Z")

</div>

Thanks @raymondk! Actually, I think we can put the binding generation in the **backend** instead of frontend, right after the build:

```yaml
# counter backend recipe
name: counter

build:
  steps:
    # 1. Build the canister (produces counter.did)
    - type: motoko # or rust
      entry: src/main.mo
      
    # 2. Generate React hooks from the .did file
    - type: script
      command: npx @ic-reactor/cli sync -c counter

sync:
  steps:
    - type: wasm

```

This way:

- The backend recipe owns both the wasm **and** the frontend bindings
- The `.did` file is guaranteed to exist when the script runs
- Frontend just needs to import from the generated hooks—no extra build steps

Would this pattern work? Or is the `build.steps` list strictly for producing wasm artifacts?

If scripts after the wasm build are supported, I could even create a **recipe template** that wraps any backend canister and adds the hook generation automatically:

```yaml
type:
  url: https://github.com/B3Pay/ic-reactor/releases/latest/recipe.hbs
  
config:
  canister: counter
  hooksDir: ../frontend/src/canisters

```

Let me know if this makes sense! 🙌

---

<div class="post-metadata">

**Author:** ![b3hr4d](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/b3hr4d/32/9755_2.png) [@b3hr4d](https://forum.dfinity.org/u/b3hr4d)\
**Post date:** [January 15, 2026, 8:59am UTC](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/13 "2026-01-15T08:59:31Z")

</div>

> [@marc0olo](#):
>
> @raymondk recorded a great demo showcasing the latest features, including the new interactive flow: 👉 **[Watch the Asciinema Demo](https://asciinema.org/a/768008)**

What a great and creative demo! Everyone should watch it!

---

<div class="post-metadata">

**Author:** ![Vivienne](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/vivienne/32/29170_2.png) [@Vivienne](https://forum.dfinity.org/u/Vivienne)\
**Post date:** [January 15, 2026, 9:13am UTC](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/14 "2026-01-15T09:13:49Z")

</div>

> [@b3hr4d](#):
>
> - The backend recipe owns both the wasm **and** the frontend bindings
> - The `.did` file is guaranteed to exist when the script runs
> - Frontend just needs to import from the generated hooks—no extra build steps
> 
> Would this pattern work? Or is the `build.steps` list strictly for producing wasm artifacts?

This pattern does work. Technically the build steps are intended to produce artifacts only, but there’s nothing stopping you from producing arbitrary side effects

Given the current setup I think this is an ok workaround, but from a composability perspective it is not great: depending on the frontend language/framework/??? you will need a different backend recipe. Your idea with the recipe template goes in the right direction for this concern

---

<div class="post-metadata">

**Author:** ![jorgenbuilder](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/jorgenbuilder/32/22166_2.png) [@jorgenbuilder](https://forum.dfinity.org/u/jorgenbuilder)\
**Post date:** [January 18, 2026, 9:22pm UTC](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/15 "2026-01-18T21:22:21Z")

</div>

I will try to create a project sometime. Big fan of the QOL additions, like the localnet simplifications and granting TCycles and ICP.

---

<div class="post-metadata">

**Author:** ![jorgenbuilder](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/jorgenbuilder/32/22166_2.png) [@jorgenbuilder](https://forum.dfinity.org/u/jorgenbuilder)\
**Post date:** [January 23, 2026, 3:54pm UTC](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/16 "2026-01-23T15:54:54Z")

</div>

Just tried it out with a toy project. Holy smokes, this is much easier to use. The CLI surface area is very intuitive. Nice work. ~~My main ask would be to add linux support (maybe it’s already there and I didn’t see it in the docs.) All of my agents (and agents in general) tend to run linux, so this feels like an important unlock.~~ (Silly me, it works great on linux!) I’ll try it out with something beyond a toy soon.

---

<div class="post-metadata">

**Author:** ![Vivienne](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/vivienne/32/29170_2.png) [@Vivienne](https://forum.dfinity.org/u/Vivienne)\
**Post date:** [January 23, 2026, 3:57pm UTC](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/17 "2026-01-23T15:57:22Z")

</div>

It already works on linux, but installation is not great yet. If you run homebrew I think it should just work with the same install instructions as on macOS. We’re working on standard package manager support

---

<div class="post-metadata">

**Author:** ![jorgenbuilder](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/jorgenbuilder/32/22166_2.png) [@jorgenbuilder](https://forum.dfinity.org/u/jorgenbuilder)\
**Post date:** [January 23, 2026, 5:51pm UTC](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/18 "2026-01-23T17:51:35Z")

</div>

I would love an agent skill for `icp-cli` [https://skills.sh/](https://skills.sh/)

---

<div class="post-metadata">

**Author:** ![marc0olo](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/marc0olo/32/17290_2.png) [@marc0olo](https://forum.dfinity.org/u/marc0olo)\
**Post date:** [January 23, 2026, 6:06pm UTC](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/19 "2026-01-23T18:06:47Z")

</div>

I will look into this, thanks for the suggestion! 👍

---

<div class="post-metadata">

**Author:** ![jorgenbuilder](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/jorgenbuilder/32/22166_2.png) [@jorgenbuilder](https://forum.dfinity.org/u/jorgenbuilder)\
**Post date:** [January 23, 2026, 7:01pm UTC](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410/20 "2026-01-23T19:01:23Z")

</div>

took a stab at it here, I’m sure it could be much better: [icp-cli-usage by jorgenbuilder/icp-skills](https://skills.sh/jorgenbuilder/icp-skills/icp-cli-usage) . an official open source dfinity/skills repo might be cool?

[Next page](https://forum.dfinity.org/t/icp-cli-announcements-and-feedback-discussion/60410.md?page=2)