mistralai/cli cli/v0.10.0

mistral CLI v0.10.0

Repository: mistralai/cli

Tag: cli/v0.10.0

Published: 2026-10-21T12:46:44Z

Prerelease: no

Release notes:

Breaking

• mistral apps init and every command that rewrites

.mistral/registries.json now record an npm-package registry's version in a separate version field, which older CLIs reject with Unrecognized key: "version". If several people work on the same app, upgrade the CLI together.

Added

• mistral apps delete [app] deletes a deployed app with its modules and

databases, after printing how many of each it removes. Without an app it deletes the one apps.json points at. Deleting that app removes its appId from apps.json, so the next deploy creates a new app. On a terminal it asks you to type the app's name, as Studio does, and elsewhere it needs --yes. Like deploy, it needs a feature flag.

Fixed

• mistral context show and mistral context set use your mistral login

session when an API key is also set, as other commands do. They used the key instead, so an expired key made context set fail with HTTP 401.

• When your sign-in has expired and cannot be renewed, the CLI also forgets the

selected organisation and workspace, as mistral logout does, and mistral context show no longer names them while your API key is in use.

• mistral apps registry update on an npm-sourced (url) registry no longer

overwrites the template files your app edited, nor brings back the ones it deleted: it updates them as on a git registry. Before asking, it fetches the new release outside your app and plans every file against the version your app vendored: untouched files follow the release, or are deleted when it no longer ships them; edited files are 3-way merged, and a merge that conflicts pauses the update until mistral apps capability merge --continue or --abort; deleted files stay deleted; new files are added. The plan, --dry-run and --json list each file's action and the CHANGELOG entries of the new versions.

• mistral apps capability update no longer keeps the template files your app

edited as they were: it 3-way merges them with the new version, as registry update does, and pauses on a merge that conflicts until mistral apps capability merge --continue or --abort.

• Both updates do the same for the template files of a capability whose npm

package ships none, which your app copied from the registry's git source. An app that copied them before this release keeps them as they are on its next update, which says so; the updates after it refresh them.

• When node_modules holds another version of a capability's package than

the one your app vendored, both updates (--dry-run included) stop before changing anything and name each package, the version installed and the one your app vendored: run bun install, or pin the package back to that version in package.json first when the pin moved. They no longer plan your files against the wrong version, or record the new version over files they did not refresh.

• mistral apps registry update (git and npm registries) and

mistral apps capability update no longer read the CLI's own Python wiring of the root pyproject.toml (each capability's dependency, uv source and exclude-newer entry) as your edits: a release that only changes the template's lines, such as requires-python, updates the file without pausing, and keeps the capabilities' Python dependencies.

• mistral apps registry update and capability update, on npm and git

registries alike, merge your app's root package.json key by key instead of line by line or replacing it: your app's name, its dependencies and every field you added or changed (trustedDependencies, your own scripts) are kept, the template's changes land, and only a key both changed pauses the update, with conflict markers around just that entry. Adding a capability that ships the root package.json merges it too, but never pauses: a key both changed keeps your value, with a warning. When the CLI cannot tell which version of the file your app started from, it takes no template change to a key your app also has: it keeps your value and warns.

• mistral apps registry update --version installs that version of

an npm-package registry's descriptor, and registry update @ works too. A version that is not published fails the update, listing the published ones. Without a version, init and registry update take the newest release rather than whatever the latest dist-tag points at, which could be a release candidate. When the registry's version list cannot be read (for example on an auth failure), they stop and say how to pin a version instead of installing the latest dist-tag.

• init --registry-package=@ records the package name and the

version separately in .mistral/registries.json, and changing the version no longer fails with descriptor-not-found: the app's descriptor cache is keyed on the package name only, an existing cache is read where it is and moved only when registry update moves the version, and registry update fetches a missing one again. When the cache is missing, registry update plans against the version the app records, fetched again, so new defaults and removals since then are still shown, and a missing cache of a registry it does not move no longer fails the update.

• mistral apps capability add, select and update install from the npm or

URL registry descriptor the app holds instead of fetching it again, so they work offline and never move the registry to a newer descriptor; only registry update does.