mise(1)

NAME

mise - Dev tools, env vars, and tasks in one CLI

SYNOPSIS

mise [OPTIONS] [<TASK>] [<TASK_ARGS>] ... [<TASK_ARGS_LAST>] ... [COMMAND]

DESCRIPTION

mise installs the development tools your projects need, sets their environment variables, and runs their tasks.

You declare tools, environment variables, and tasks in mise.toml. `mise use <TOOL>` installs a tool and adds it to the project's mise.toml, `mise install` installs everything the config requests, and `mise run <TASK>` runs a task. Docs: https://mise.jdx.dev

OPTIONS

-c, --continue-on-error

Continue running tasks even if one fails

-C, --cd <DIR>

Run as if mise were started in DIR

-E, --env <ENV>

Load the `mise.<ENV>.toml` config files (same as MISE_ENV)

Repeat the flag or separate names with commas to load several environments.

-f, --force

Force the operation

-j, --jobs <JOBS>

How many jobs to run in parallel; defaults to the `jobs` setting

Values below 1 are treated as 1.

Environment: MISE_JOBS

-n, --dry-run

Dry run, don't actually do anything

-P, --profile <PROFILE>

Set the profile (environment)

-q, --quiet

Suppress non-error messages

Environment: MISE_QUIET

-s, --shell <SHELL>

-t, --tool <TOOL@VERSION>

Tools to load in addition to those in mise.toml, such as `node@24 [email protected]`

-v, --verbose

Show extra output (use -vv for even more)

-V, --version

-y, --yes

Answer yes to all confirmation prompts

--debug

Set the log level to debug

--log-level <LEVEL>

--no-config

Do not load any config files

Same as `MISE_NO_CONFIG=1`.

--no-env

Do not load environment variables from config files

Same as `MISE_NO_ENV=1`.

--no-hooks

Do not run hooks from config files

Same as `MISE_NO_HOOKS=1`.

--no-timings

Hide the elapsed time printed after each task completes

Set `MISE_TASK_TIMINGS=0` to hide it by default

--output <OUTPUT>

How task output is displayed when running a task (same as `mise run --output`)

--raw

Connect tasks and install commands directly to the terminal

Commands then run one at a time. Same as `MISE_RAW=1` or the `raw` setting.

--locked

Require download URLs from the lockfile when installing

Installing fails when the lockfile has no pre-resolved URL for a tool on the current platform, so mise does not call the GitHub or aqua registry APIs to find one. Same as `MISE_LOCKED=1` or the `locked` setting.

--silent

Suppress all task output and mise non-error messages

--timings

Show the elapsed time after each task completes

Set `MISE_TASK_TIMINGS=1` to show it by default

--trace

Set the log level to trace

-h, --help

Print help

ARGUMENTS

<TASK>

Task to run

Shorthand for `mise run <TASK>`.

<TASK_ARGS>

Task arguments

COMMANDS

activate

Print the script to activate mise in an interactive shell

tool-alias

Manage tool backend and version aliases

Aliases: alias, aliases

tool-alias get

Show the version a tool's version alias stands for

tool-alias ls

List tool version aliases

Aliases: list

tool-alias set

Set a backend alias or a version alias in the global config

Aliases: add, create

tool-alias unset

Remove a backend alias or a version alias from the global config

Aliases: rm, remove, delete, del

backends

Manage backends

Aliases: b, backend, backend-list

backends ls

List built-in backends

Aliases: list

backends switch

Switch tools to the backend the registry now installs them from

bin-paths

List the bin directories of the active tools

bootstrap

Set up this machine from your mise config

Aliases: bs

bootstrap accounts

Manage Linux users and groups

bootstrap accounts apply

Create, update, or remove the configured Linux users and groups

bootstrap accounts status

Show the state of the configured Linux users and groups

bootstrap compose

Manage Docker Compose projects from `[bootstrap.compose]`

bootstrap compose apply

Apply Docker Compose projects from `[bootstrap.compose]`

bootstrap compose status

Show the state of Docker Compose projects from `[bootstrap.compose]`

bootstrap files

Manage system files and directories declared in `[bootstrap]`

bootstrap files apply

Create, update, or remove the configured system files and directories

bootstrap files status

Show the state of the configured system files and directories

bootstrap firewall

Manage the Linux host firewall from `[bootstrap.linux.firewall]`

bootstrap firewall apply

Apply the firewall from `[bootstrap.linux.firewall]`

bootstrap firewall status

Show the state of the firewall from `[bootstrap.linux.firewall]`

bootstrap linux

Manage systemd user units from `[bootstrap.linux.systemd.units]`

bootstrap linux systemd-units

Manage systemd user units from `[bootstrap.linux.systemd.units]`

Aliases: systemd

bootstrap linux systemd-units apply

Install and start the configured systemd user units

bootstrap linux systemd-units status

Show the state of the configured systemd user units

bootstrap macos

Manage macOS preferences and LaunchAgents from `[bootstrap.macos]`

bootstrap macos defaults

Manage macOS preferences such as Dock, Finder, and keyboard settings

bootstrap macos defaults apply

Write the configured macOS preferences

bootstrap macos defaults status

Show the state of the configured macOS preferences

bootstrap macos launchd-agents

Manage macOS LaunchAgents from `[bootstrap.macos.launchd.agents]`

Aliases: launchd

bootstrap macos launchd-agents apply

Install and load LaunchAgents from `[bootstrap.macos.launchd.agents]`

bootstrap macos launchd-agents status

Show the state of the configured LaunchAgents

bootstrap mise-shell-activate

Manage mise shell activation from `[bootstrap.mise_shell_activate]`

Aliases: shell

bootstrap mise-shell-activate apply

Write mise activation into the configured shell startup files

bootstrap mise-shell-activate status

Show the state of the configured shell activation

bootstrap packages

Manage packages from `[bootstrap.packages]`

bootstrap packages apply

Install or remove packages to match `[bootstrap.packages]`

Aliases: i, install

bootstrap packages brew

Manage Homebrew tap URLs in `[bootstrap.brew.taps]`

bootstrap packages brew tap

Add a Homebrew tap URL to the global `[bootstrap.brew.taps]`

bootstrap packages brew untap

Remove Homebrew tap URLs from `[bootstrap.brew.taps]`

Aliases: remove, rm

bootstrap packages export

Print the configured `nix:` packages as a NixOS module

bootstrap packages import

Record installed Homebrew formulae in `[bootstrap.packages]`

bootstrap packages prune

Uninstall packages that no config declares

bootstrap packages status

Show the state of packages from `[bootstrap.packages]`

Aliases: ls, list

bootstrap packages upgrade

Upgrade installed packages from `[bootstrap.packages]`

Aliases: up

bootstrap packages use

Add packages to `[bootstrap.packages]` and install them

Aliases: u

bootstrap packages where

Print the `opt` path of an installed Homebrew formula

bootstrap plan

Show what applying bootstrap resources would change

bootstrap plugins

Manage package manager plugins declared in `[bootstrap.plugins]`

bootstrap plugins apply

Install package manager plugins declared in `[bootstrap.plugins]`

bootstrap plugins status

Show whether declared package manager plugins are installed

bootstrap remote

Bootstrap one or more machines over SSH

bootstrap repos

Manage Git repositories from `[bootstrap.repos]`

bootstrap repos apply

Clone missing Git repositories and check out configured refs

bootstrap repos exec

Run a command in each configured Git repository

bootstrap repos status

Show the state of Git repositories from `[bootstrap.repos]`

bootstrap repos update

Clone missing Git repositories and fast-forward the rest

bootstrap secrets

Inspect bootstrap secret inputs without revealing their values

bootstrap secrets status

Show whether declared bootstrap secret inputs are available

bootstrap services

Manage services from `[bootstrap.services]`

bootstrap services apply

Apply the service state declared in `[bootstrap.services]`

bootstrap services remove

Uninstall a user-scope service

bootstrap services status

Show the state of services from `[bootstrap.services]`

bootstrap status

Show the state of every configured bootstrap part

Aliases: ls

bootstrap unapply

Remove what a config environment's bootstrap sections created

bootstrap user

Manage your login shell from `[bootstrap.user]`

bootstrap user apply

Set your login shell from `[bootstrap.user]`

bootstrap user status

Show whether your login shell matches `[bootstrap.user]`

cache

Manage the mise cache

cache clear

Delete cached data

Aliases: c, clean

cache path

Print the cache directory path

Aliases: dir

cache prune

Remove cache files that have not been accessed recently

Aliases: p

cache task

[experimental] Inspect artifact cache entries for a task

completion

Generate shell completions

Aliases: complete, completions

config

Manage config files

Aliases: cfg, toml

config explain

Describe each key in a mise TOML file

config get

Print a value from one mise TOML file

config ls

List config files currently in use, from lowest to highest precedence

Aliases: list

config set

Set a value in one mise TOML file

deactivate

Print the script to disable mise in the current shell session

daemons

[experimental] Manage project daemons with pitchfork

Aliases: daemon

daemons providers

[experimental] Manage shared servers from global `[daemon_providers]`

daemons providers ls

[experimental] List shared servers

daemons providers start

[experimental] Start shared servers

daemons providers stop

[experimental] Stop shared servers (data is kept)

daemons providers restart

[experimental] Restart shared servers with their current configuration

daemons start

[experimental] Start project daemons and the daemons they depend on

daemons register

[experimental] Register project daemons for on-demand startup

daemons stop

[experimental] Stop project daemons

daemons restart

[experimental] Restart project daemons

daemons ls

[experimental] List project daemons

Aliases: list

daemons urls

[experimental] Show each daemon's URL and port

daemons logs

[experimental] Show the output of project daemons

daemons status

[experimental] Show the status of project daemons

daemons tui

[experimental] Open the pitchfork dashboard

daemons prune

[experimental] Remove daemon state left by deleted projects

dotfiles

Deploy, track, and sync dotfiles

Aliases: dot

dotfiles add

Start deploying a file, or copy its edits back to the source

dotfiles apply

Link, copy, and render `[dotfiles]` entries into place

dotfiles capture

Run a command and save tracked files before and after it

dotfiles conflicts

Compare both sides of a sync conflict

dotfiles diff

Show what `mise dot apply` would change

dotfiles edit

Open a dotfile's source in your editor

dotfiles exclude

Never save paths matching a glob

dotfiles history

Browse saved versions of your tracked files

dotfiles history describe

Set the description of a checkpoint

dotfiles history diff

Compare checkpoints, or your files against one

dotfiles history ls

List checkpoints, newest first

Aliases: list

dotfiles history purge

Erase a path's saved versions from history

dotfiles history show

Show a checkpoint: its trigger, changes, and operation journal

dotfiles include

Stop excluding paths matching a glob

dotfiles notify

Send a test desktop notification

dotfiles origin

Show, connect, or disconnect the origin repository

dotfiles origin set

Connect an origin repository

dotfiles paths

List tracked paths and how they are saved

dotfiles pull

Write fetched changes from other machines to tracked files

dotfiles recover

Recover an interrupted dotfile operation

dotfiles rollback

Return files to the version a checkpoint holds

dotfiles save

Save a checkpoint of the tracked files now

dotfiles status

Show the state of your dotfiles and their history

Aliases: ls

dotfiles sync

Push saved checkpoints and fetch incoming changes

dotfiles track

Track a file or directory in place

dotfiles unapply

Remove files that `mise dot apply` deployed

dotfiles undo

Reverse the tracked-file changes from an operation

dotfiles untrack

Stop tracking a file or directory

dotfiles watch

Save tracked files as they change

doctor

Check your mise setup for problems

Aliases: dr

doctor path

Print the directories mise adds to PATH

Aliases: paths

doctor project

Run the project's diagnostic checks

en

Start a subshell with mise's tools and environment

env

Print the environment for the current configuration

Aliases: e

exec

Run a command with mise's tools and environment

Aliases: x

fmt

Format mise TOML configuration

generate

Generate project files such as CI workflows, git hooks, and scripts

Aliases: gen, g

generate config

Generate a mise.toml file

generate devcontainer

Generate a devcontainer configuration that installs mise and the project's tools

generate git-pre-commit

Generate a git hook that runs a mise task

Aliases: pre-commit

generate github-action

Generate a GitHub Actions workflow that runs a mise task

generate install-script

Generate a script that downloads and runs a pinned mise

generate task-docs

Generate Markdown documentation for project tasks

generate task-stubs

Generate scripts that run mise tasks

generate tool-stub

Generate or update a tool stub

implode

Remove the mise CLI and all related data

edit

Edit mise.toml interactively

install

Install the tools in your config, or specific tool versions

Aliases: i

install-into

Install a tool version into a directory outside mise

installs

[experimental] Inspect and choose identity-layout installations

installs ls

List the installations of the identity install layout

Aliases: list

installs migrate

Reinstall legacy installations into the identity install layout

installs select

Choose which installation mise uses when no lockfile pins one

latest

Print the latest version that matches a version request

link

Symlink a tool version into mise

Aliases: ln

lock

Create or refresh lockfile versions, checksums, and download URLs

ls

List installed and active tool versions

Aliases: list

ls-remote

List tool versions available to install

Aliases: list-all, list-remote

lsp

Run the language server for mise config files over stdin/stdout

mcp

Run the Model Context Protocol server over stdin/stdout

oci

[experimental] Build, push, and run OCI images of a project's tools

oci build

[experimental] Build an OCI image from the current mise.toml

oci push

[experimental] Build an OCI image and push it to a registry

oci run

[experimental] Build the project's image and run a command in it

packslip

Inspect and reset the signers mise has pinned for packslip tools

packslip forget

Forget a project's pinned signer so the next accepted release sets it

packslip pins

List the signer mise has pinned for each packslip project

Aliases: list

outdated

Show outdated tool versions

patrons

Show the individuals supporting mise as Patron-tier members

plugins

Manage plugins

Aliases: p, plugin, plugin-list

plugins install

Install plugins from a configured source, Git URL, or archive

Aliases: i, a, add

plugins link

Link a local plugin directory into mise for development

Aliases: ln

plugins ls

List installed plugins

Aliases: list

plugins ls-remote

List registry tools that have an asdf or vfox plugin backend

Aliases: list-remote, list-all

plugins uninstall

Remove an installed plugin

Aliases: remove, rm

plugins update

Update installed plugins

Aliases: up, upgrade

deps

[experimental] Manage project dependencies

Aliases: dep, prepare

deps add

Add packages to the project's dependencies

deps install

Install project dependencies

deps remove

Remove packages from the project's dependencies

prune

Delete tool versions that nothing uses

registry

List registry shorthand names and their backends

reshim

Create shims for executables provided by installed tools

run

Run tasks and their dependencies

Aliases: r

search

Search for available tools

secrets

[experimental] Inspect the project's secrets source

secrets ls

[experimental] List secret names from the project's secrets source

Aliases: list

self-update

Update mise itself

set

Set, show, or list environment variables in mise.toml

Aliases: ev, env-vars

settings

Manage settings

settings add

Append a value to an array setting

settings get

Show the effective value of a setting

settings ls

List configured settings and their sources

Aliases: list

settings set

Set a setting

Aliases: create

settings unset

Remove a setting from the global or project config

Aliases: rm, remove, delete, del

shell

Set a tool version for the current shell session

Aliases: sh

ssh

Open an SSH session, optionally borrowing read-only GitHub access

shell-alias

Manage shell aliases

shell-alias get

Show the command for a shell alias

shell-alias ls

List shell aliases

Aliases: list

shell-alias set

Set a shell alias in the global config

Aliases: add, create

shell-alias unset

Remove a shell alias from the global config

Aliases: rm, remove, delete, del

skills

List and link the agent skills that active tools ship

Aliases: skill

skills ls

List the skills the active tools declare

Aliases: list

skills sync

Link the active tools' skills where an agent looks for them

sponsors

Show the companies sponsoring mise and the jdx.dev open source tools

sync

Use tool versions installed by other version managers

sync node

Symlink node versions installed by nvm, nodenv, or Homebrew into mise

sync python

Symlink python versions installed by pyenv or uv into mise

sync ruby

Symlink ruby versions installed by Homebrew into mise

tasks

Manage tasks

Aliases: t, task

tasks add

Add a task

tasks deps

Show the dependency tree of tasks

tasks edit

Open a task in your editor

tasks graph

Show the monorepo project graph

tasks info

Show a task's definition

tasks ls

List available tasks

tasks validate

Check task definitions for errors

test-tool

Test that a tool installs and runs

token

Show which Git provider token mise uses

token forgejo

Show the Forgejo token mise uses for a host

token github

Show the GitHub token mise uses for a host

token gitlab

Show the GitLab token mise uses for a host

tool

Show information about a tool

tool-stub

Run a tool stub file

trust

Mark a config file as trusted

uninstall

Remove installed tool versions

unset

Remove environment variables from mise.toml

untrust

Remove explicit trust for a config

unuse

Remove tool requests from config files and prune unused installations

Aliases: rm, remove

upgrade

Upgrade outdated tools

Aliases: up

use

Install a tool and add it to configuration

Aliases: u

vars

List, set, and ask for config vars

vars ls

List every var, with the file it comes from

Aliases: list

vars prompt

Ask for the prompt vars that have no saved answer, or set answers directly

vars unset

Forget saved answers so they are asked for again

Aliases: rm, remove

version

Show the version of mise

Aliases: v

watch

Run tasks and rerun them when files change

Aliases: w

where

Show the install directory of a tool version

which

Show the path a tool's executable resolves to

MISE ACTIVATE

Print the script to activate mise in an interactive shell

Evaluate this command's output with the syntax for your shell; running it alone only prints the script. Activation updates tools and environment variables as this shell changes directories.

Add the matching example below once to your interactive startup file: ~/.bashrc for Bash, ~/.zshrc for Zsh, ~/.config/fish/config.fish for Fish, or $PROFILE for PowerShell. For Nushell, Elvish and other shells, see https://mise.jdx.dev/shell-setup.html.

The mise executable must be on PATH before that line runs. Otherwise use its absolute path, for example `eval "$(~/.local/bin/mise activate zsh)"`.

Use `mise exec -- command` for scripts and CI that do not need interactive hooks. The `status.*` settings control the messages mise prints when you change directories.

Usage: mise activate [OPTIONS] [<SHELL_TYPE>]

Options:

-q, --quiet

Suppress non-error messages from the hook that runs at each prompt

-s, --shell <SHELL>

Shell type to generate the script for

--no-hook-env

Do not run hook-env automatically

Use it for debugging: after `eval "$(mise activate zsh --no-hook-env)"`, run `mise hook-env` yourself to print the shell code it would evaluate, or `mise hook-env --trace` for more detail.

--shims

Put the shims directory on PATH instead of updating PATH at each prompt

Roughly equivalent to:

PATH="$HOME/.local/share/mise/shims:$PATH"

Shims do not support every feature of `mise activate`; see https://mise.jdx.dev/dev-tools/shims.html#shims-vs-path.

--status

Show "mise: <TOOL>@<VERSION>" message when changing directories

-h, --help

Print help Arguments:

<SHELL_TYPE>

Shell type to generate the script for

Defaults to the shell named by MISE_SHELL or SHELL. mise reports an error when neither names a supported shell, as in PowerShell and cmd on Windows. Examples:

Activate mise in Bash

Activate mise in Zsh

Activate mise in Fish

Activate mise in Xonsh

Activate mise in PowerShell

MISE TOOL-ALIAS

Manage tool backend and version aliases

A backend alias makes a tool name install from another backend: `[tool_alias] ripgrep = "aqua:BurntSushi/ripgrep"`. A version alias names a version request: `[tool_alias.node.versions] project = "20"` lets you write `node@project`.

With no subcommand, lists version aliases (same as `mise tool-alias ls`; the flags below are passed to it). See https://mise.jdx.dev/dev-tools/aliases.html

Usage: mise tool-alias [OPTIONS] [COMMAND]

Options:

-p, --tool <TOOL>

Filter aliases by tool

--no-header

Do not print the table header

-h, --help

Print help

MISE TOOL-ALIAS GET

Show the version a tool's version alias stands for

Reads `[tool_alias.TOOL.versions]` from every loaded config file and the aliases the tool's backend provides, such as node's `lts-*` aliases. It prints the stored request, which may itself be a prefix.

Usage: mise tool-alias get [OPTIONS] <TOOL> <ALIAS>

Options:

-h, --help

Print help Arguments:

<TOOL>

The tool to show the alias for

<ALIAS>

The alias to show Examples:

Show the version node's lts alias stands for

Read back an alias you set

MISE TOOL-ALIAS LS

List tool version aliases

Lists version aliases from `[tool_alias.<tool>.versions]` in any loaded config file and the aliases that tool backends provide, such as node's `lts-*` names or an asdf plugin's `bin/list-aliases`. For example:

[tool_alias.node.versions]
project = "20"

Backend aliases (`[tool_alias] tool = "backend"`) are not listed; run `mise tool <TOOL>` to see the backend a tool uses.

Usage: mise tool-alias ls [OPTIONS] [<TOOL>]

Options:

--no-header

Do not print the table header

-h, --help

Print help Arguments:

<TOOL>

Only show aliases for this tool Examples:

List node's version aliases

MISE TOOL-ALIAS SET

Set a backend alias or a version alias in the global config

`mise tool-alias set TOOL BACKEND` makes TOOL install from BACKEND, written as `[tool_alias] TOOL = "BACKEND"`. `mise tool-alias set TOOL ALIAS VERSION` makes `TOOL@ALIAS` mean VERSION, written under `[tool_alias.TOOL.versions]`. Writes the global config (~/.config/mise/config.toml by default); add aliases to a project's mise.toml to share them.

Usage: mise tool-alias set [OPTIONS] <TOOL> <ALIAS> [<VALUE>]

Options:

-h, --help

Print help Arguments:

<TOOL>

The tool to alias

<ALIAS>

The version alias to set, or the backend when VALUE is omitted

<VALUE>

The version request the alias stands for Examples:

Install ripgrep from its aqua backend

Make node@project mean node@20

MISE TOOL-ALIAS UNSET

Remove a backend alias or a version alias from the global config

With only TOOL, removes the tool's backend alias. With TOOL and ALIAS, removes that version alias. Edits the global config (~/.config/mise/config.toml by default).

Usage: mise tool-alias unset [OPTIONS] <TOOL> [<ALIAS>]

Options:

-h, --help

Print help Arguments:

<TOOL>

The tool to remove the alias from

<ALIAS>

The version alias to remove; omit it to remove the backend alias Examples:

Remove ripgrep's backend alias

Remove node's project version alias

MISE BACKENDS

Manage backends

A backend is where mise installs a tool from: a package registry such as npm or cargo, a release host such as GitHub, or a plugin. Each tool uses one, either written as a prefix (`npm:prettier`) or chosen by the registry. With no subcommand, lists the built-in backends. See https://mise.jdx.dev/dev-tools/backends/.

Usage: mise backends [OPTIONS] [COMMAND]

Options:

-h, --help

Print help

MISE BACKENDS LS

List built-in backends

Backends that plugins add are listed by `mise plugins ls`.

Usage: mise backends ls [OPTIONS]

Options:

-h, --help

Print help Examples:

List the backends built into mise

MISE BACKENDS SWITCH

Switch tools to the backend the registry now installs them from

When the registry moves a tool to another backend, mise keeps installing it from the backend recorded in mise.lock and warns that the registry has a newer one. This moves those lock entries to the registry's backend at the same versions, relocks them to record the new backend's checksums and URLs, and reinstalls installed versions so they come from the new backend.

It covers the lockfiles `mise lock` writes: the current project's, or the global config's with `--global`.

Usage: mise backends switch [OPTIONS] [<TOOL@VERSION>] ...

Options:

-n, --dry-run

Show what would switch without changing the lockfile or installs

-g, --global

Switch tools in the global config's lockfile instead of the project's

-h, --help

Print help Arguments:

<TOOL@VERSION>

Tools to switch

Defaults to every configured tool whose locked backend the registry has replaced. A version (`[email protected]`) limits the switch to that version. Examples:

Move communique to the registry's current backend

List every locked tool the registry now installs from another backend

MISE BIN-PATHS

List the bin directories of the active tools

Prints the bin directories of the tool versions the current config selects. It does not include `_.path` entries from [env]; `mise doctor path` lists everything mise adds to PATH.

Usage: mise bin-paths [OPTIONS] [<TOOL@VERSION>] ...

Options:

--bin-names

Print executable names instead of bin directories

-J, --json

Print executables as JSON objects with `name`, `path`, and `symlink` (implies --bin-names)

-h, --help

Print help Arguments:

<TOOL@VERSION>

Only list these tools, such as `ruby@3` Examples:

Print the bin directory of every active tool

Print only node's bin directory

List the executables the active tools provide

MISE BOOTSTRAP

Set up this machine from your mise config

Applies each part your config declares, in this order. Each step names its parts as `--only` and `--skip` accept them, followed by any condition.

1. `accounts`, then `plugins` (package manager plugins) 2. `files` with `phase = "pre-packages"`, then built-in `packages` 3. The remaining `files`, then `services`, `firewall`, and `compose` 4. `repos`, then `dotfiles` 5. `mise-shell-activate`, `macos-defaults`, and `macos-launchd-agents` 6. `linux-systemd-units`, then `user` (the login shell) 7. `tools` 8. Plugin `packages`, then user `services` with `requires_tools = true` 9. `task` (the `bootstrap` task, if defined), then `final-hook`

Hooks run before and after packages, repos, dotfiles, macOS defaults, the login shell, and tools. The post-packages hook runs right after built-in packages, or after plugin packages when any are configured. See https://mise.jdx.dev/bootstrap.html#how-it-runs.

Parts that already match the config are left alone, but hooks and the `bootstrap` task run every time, so make them safe to repeat. Checking dotfile state can render templates, which may run `exec()`.

Preview with `--dry-run`. To inspect without applying, use `mise bootstrap status` for current state or `mise bootstrap plan` for resource-level changes.

Usage: mise bootstrap [OPTIONS] [COMMAND]

Options:

--from <GIT_URL>

Clone a bootstrap project (a Git repository with a mise.toml) and apply it

The checkout is reused on later runs; add `--update` to fast-forward it first. Append `?ref=<branch|tag|commit>` to check out a ref instead of the default branch, for example `https://github.com/example/workstation.git?ref=v1`. See https://mise.jdx.dev/bootstrap/from-repository.html.

--adopt <GIT_URL|OWNER/REPO>

Clone a repository of global mise config or dotfile history, then apply it

A repository of global config (`config.toml`, `conf.d/`, `tasks/`) is cloned into the global config directory, normally ~/.config/mise. A setup repository shared with `mise dotfiles origin set` restores its tracked files instead. `OWNER/REPO` is short for `https://github.com/OWNER/REPO.git`. Append `?ref=<branch>` to adopt a branch other than the default branch.

--replace-history

Discard this machine's dotfile history and adopt the repository's

Use it with `--adopt` when the two histories are unrelated. Files that differ from the repository still stop the adoption until you resolve them, or add `--take-remote-all` to take the repository's version of each.

--take-remote-all

Take the setup repository's version of every existing file that differs while adopting

The replaced versions are saved first, so `mise dot undo` restores them.

--from-dir <DIR>

Directory for the `--from` checkout (default: `$MISE_DATA_DIR/bootstrap-repo`)

--config-dir <DIR>

Link the global config directory to this directory of the `--from` checkout

mise links its config directory, normally ~/.config/mise, to the directory, then bootstraps from it, so its `config.toml`, `config.<env>.toml`, `conf.d/`, and `miserc.toml` are the global config from this run on. The directory must exist in the checkout, and the path to it is relative to the checkout and must stay inside it; `.` is the checkout itself. mise's config directory, where the link goes, must be missing, empty, or already this link. See https://mise.jdx.dev/bootstrap/from-repository.html#global-config-elsewhere.

-n, --dry-run

Show what would change without changing anything

Hooks and the `bootstrap` task are printed instead of run.

-y, --yes

Skip confirmation prompts

--skip-dirty

Skip configured repositories with local changes instead of failing

--force-dotfiles

Overwrite existing files that conflict with whole-file dotfile entries

--prune-dotfiles

Remove files that dotfile groups deployed but no active entry deploys now

The same pruning as `mise dot apply --prune`, run at the end of the dotfiles phase before its post hook: files of a group that is no longer selected or declared, and files a group stopped deploying because of a new `exclude` or a deleted source. Changed copies stay in place, and mise asks before removing anything unless `--yes` is given or there is no terminal. With `--dry-run`, nothing is removed.

--only <PART>

Run only these parts

Repeat the flag or separate parts with commas. Cannot be combined with `--skip`.

--prompt-secrets

Prompt securely for missing bootstrap secret inputs

--prompt-vars

Ask for `[vars]` entries that declare a `prompt` and have no saved answer

mise saves each answer under `$MISE_STATE_DIR`, not in any config file, and never asks for it again. Without a terminal, a var keeps its default. A `--dry-run` still saves the answers it asks for.

--skip <PART>

Skip these parts

Repeat the flag or separate parts with commas. Cannot be combined with `--only`.

--update

Refresh package metadata and update repositories before applying

Also fast-forwards a checkout that `--from` or `--adopt` reuses. Without `--update`, a reused checkout stays at its current commit.

--upgrade

Upgrade installed packages and tools as well as installing missing ones

In the packages phase, runs the equivalent of `mise bootstrap packages upgrade` after installing; in the tools phase, runs `mise upgrade` (without `--bump`) after installing. Package pins and tool version ranges are respected. Does not update mise itself, repositories, or container images, and does not restart services; see `--update` for repositories and `mise self-update` for mise.

-h, --help

Print help Examples:

Preview every configured part

Apply every configured part

Apply only dotfiles and tools

Apply everything except tools and the bootstrap task

Replace files that conflict with whole-file dotfile entries

Clone a bootstrap project and apply it

Do the same and also load the project's mise.work.toml

Clone a dotfiles repository and link ~/.config/mise to its .config/mise

Clone global config into ~/.config/mise, then apply it

Use a setup repository's dotfile history instead of this machine's

Refresh package metadata and fast-forward repositories first

MISE BOOTSTRAP ACCOUNTS

Manage Linux users and groups

Creates, updates, or removes the local accounts declared in `[bootstrap.users]` and `[bootstrap.groups]` on Linux. Run `status` or `apply --dry-run` before changing user IDs, group memberships, or account state.

Usage: mise bootstrap accounts [OPTIONS] <COMMAND>

Options:

-h, --help

Print help

MISE BOOTSTRAP ACCOUNTS APPLY

Create, update, or remove the configured Linux users and groups

Usage: mise bootstrap accounts apply [OPTIONS]

Options:

-n, --dry-run

Show what would change without changing anything

-y, --yes

Skip the confirmation prompt

-h, --help

Print help

MISE BOOTSTRAP ACCOUNTS STATUS

Show the state of the configured Linux users and groups

Usage: mise bootstrap accounts status [OPTIONS]

Options:

-J, --json

Output in JSON format

--missing

Exit with status 1 if any account differs from the config (all are still listed)

-h, --help

Print help

MISE BOOTSTRAP COMPOSE

Manage Docker Compose projects from `[bootstrap.compose]`

Needs a running Docker engine and the Docker Compose command on this machine.

Usage: mise bootstrap compose [OPTIONS] <COMMAND>

Options:

-h, --help

Print help Examples:

Show the state of every declared project

Show what would change

MISE BOOTSTRAP COMPOSE APPLY

Apply Docker Compose projects from `[bootstrap.compose]`

Usage: mise bootstrap compose apply [OPTIONS]

Options:

-n, --dry-run

Show what would change without changing anything

-y, --yes

Skip the confirmation prompt

-h, --help

Print help

MISE BOOTSTRAP COMPOSE STATUS

Show the state of Docker Compose projects from `[bootstrap.compose]`

Usage: mise bootstrap compose status [OPTIONS]

Options:

-J, --json

Output in JSON format

--missing

Exit with status 1 if any Compose project differs from the config (all are still listed)

-h, --help

Print help

MISE BOOTSTRAP FILES

Manage system files and directories declared in `[bootstrap]`

Applies `[bootstrap.files]` and `[bootstrap.directories]`: paths that need a specific owner, group, or mode, or that must exist or be absent system-wide, such as configuration under /etc. For files in your home directory that you edit, use `[dotfiles]` and `mise dotfiles`.

Usage: mise bootstrap files [OPTIONS] <COMMAND>

Options:

-h, --help

Print help Examples:

Exit with status 1 if any file or directory differs from the config

Show what would change

Apply without a prompt

MISE BOOTSTRAP FILES APPLY

Create, update, or remove the configured system files and directories

Usage: mise bootstrap files apply [OPTIONS]

Options:

-n, --dry-run

Show what would change without changing anything

-y, --yes

Skip the confirmation prompt

--prompt-secrets

Prompt securely for missing bootstrap secret inputs

-h, --help

Print help

MISE BOOTSTRAP FILES STATUS

Show the state of the configured system files and directories

Usage: mise bootstrap files status [OPTIONS]

Options:

-J, --json

Output in JSON format

--missing

Exit with status 1 if any file or directory differs from the config (all are still listed)

--prompt-secrets

Prompt securely for missing bootstrap secret inputs

-h, --help

Print help

MISE BOOTSTRAP FIREWALL

Manage the Linux host firewall from `[bootstrap.linux.firewall]`

Works with nftables, firewalld, or UFW, and keeps mise's rules separate from other host rules. Over SSH, mise refuses a default incoming policy of deny or reject unless a rule allows the current connection or the config sets `allow_lockout = true`. Check `apply --dry-run` before applying a policy to a remote machine.

Usage: mise bootstrap firewall [OPTIONS] <COMMAND>

Options:

-h, --help

Print help Examples:

Show the firewall's state

Show the policy and rules that would change

MISE BOOTSTRAP FIREWALL APPLY

Apply the firewall from `[bootstrap.linux.firewall]`

Usage: mise bootstrap firewall apply [OPTIONS]

Options:

-n, --dry-run

Show what would change without changing anything

-y, --yes

Skip the confirmation prompt

-h, --help

Print help

MISE BOOTSTRAP FIREWALL STATUS

Show the state of the firewall from `[bootstrap.linux.firewall]`

Usage: mise bootstrap firewall status [OPTIONS]

Options:

-J, --json

Output in JSON format

--missing

Exit with status 1 if the firewall differs from the config

-h, --help

Print help

MISE BOOTSTRAP LINUX

Manage systemd user units from `[bootstrap.linux.systemd.units]`

The host firewall in `[bootstrap.linux.firewall]` is managed by `mise bootstrap firewall`.

Usage: mise bootstrap linux [OPTIONS] <COMMAND>

Options:

-h, --help

Print help

MISE BOOTSTRAP LINUX SYSTEMD-UNITS

Manage systemd user units from `[bootstrap.linux.systemd.units]`

Writes unit files to ~/.config/systemd/user, then enables and starts them as configured. An entry with `state = "absent"` is stopped, disabled, and deleted instead. Units run with your permissions and need a reachable systemd user manager. For system units, or a user service that also works on macOS and Windows, use `[bootstrap.services]`.

Usage: mise bootstrap linux systemd-units [OPTIONS] <COMMAND>

Options:

-h, --help

Print help

MISE BOOTSTRAP LINUX SYSTEMD-UNITS APPLY

Install and start the configured systemd user units

Usage: mise bootstrap linux systemd-units apply [OPTIONS]

Options:

-n, --dry-run

Show what would change without changing anything

-y, --yes

Skip the confirmation prompt

-h, --help

Print help

MISE BOOTSTRAP LINUX SYSTEMD-UNITS STATUS

Show the state of the configured systemd user units

Usage: mise bootstrap linux systemd-units status [OPTIONS]

Options:

-J, --json

Output in JSON format

--missing

Exit with status 1 if any unit differs from the config (all are still listed)

-h, --help

Print help

MISE BOOTSTRAP MACOS

Manage macOS preferences and LaunchAgents from `[bootstrap.macos]`

Usage: mise bootstrap macos [OPTIONS] <COMMAND>

Options:

-h, --help

Print help

MISE BOOTSTRAP MACOS DEFAULTS

Manage macOS preferences such as Dock, Finder, and keyboard settings

Applies `[bootstrap.macos.defaults]`, `[[bootstrap.macos.defaults_entries]]`, and the `[bootstrap.macos.dock]`, `finder`, `keyboard`, and `trackpad` sections. Preferences are written the way `defaults write` writes them. mise does not restart apps: Dock, Finder, and some others show a change only after they relaunch.

Usage: mise bootstrap macos defaults [OPTIONS] <COMMAND>

Options:

-h, --help

Print help

MISE BOOTSTRAP MACOS DEFAULTS APPLY

Write the configured macOS preferences

Usage: mise bootstrap macos defaults apply [OPTIONS]

Options:

-n, --dry-run

Show what would change without changing anything

-y, --yes

Skip the confirmation prompt

-h, --help

Print help

MISE BOOTSTRAP MACOS DEFAULTS STATUS

Show the state of the configured macOS preferences

Usage: mise bootstrap macos defaults status [OPTIONS]

Options:

-J, --json

Output in JSON format

--missing

Exit with status 1 if any preference differs from the config (all are still listed)

-h, --help

Print help

MISE BOOTSTRAP MACOS LAUNCHD-AGENTS

Manage macOS LaunchAgents from `[bootstrap.macos.launchd.agents]`

Writes each agent to ~/Library/LaunchAgents/dev.mise.<name>.plist and loads it into your GUI login session. Run it as the user who owns the agents; an SSH session without a GUI login may not be able to load them. For a user service that also works on Linux and Windows, use `[bootstrap.services]` with `scope = "user"`.

Usage: mise bootstrap macos launchd-agents [OPTIONS] <COMMAND>

Options:

-h, --help

Print help

MISE BOOTSTRAP MACOS LAUNCHD-AGENTS APPLY

Install and load LaunchAgents from `[bootstrap.macos.launchd.agents]`

Usage: mise bootstrap macos launchd-agents apply [OPTIONS]

Options:

-n, --dry-run

Show what would change without changing anything

-y, --yes

Skip the confirmation prompt

-h, --help

Print help

MISE BOOTSTRAP MACOS LAUNCHD-AGENTS STATUS

Show the state of the configured LaunchAgents

Usage: mise bootstrap macos launchd-agents status [OPTIONS]

Options:

-J, --json

Output in JSON format

--missing

Exit with status 1 if any LaunchAgent differs from the config (all are still listed)

-h, --help

Print help

MISE BOOTSTRAP MISE-SHELL-ACTIVATE

Manage mise shell activation from `[bootstrap.mise_shell_activate]`

Writes a managed activation block into each configured shell startup file. It does not activate mise in the shell you run it from; open a new shell afterward.

Usage: mise bootstrap mise-shell-activate [OPTIONS] <COMMAND>

Options:

-h, --help

Print help

MISE BOOTSTRAP MISE-SHELL-ACTIVATE APPLY

Write mise activation into the configured shell startup files

Usage: mise bootstrap mise-shell-activate apply [OPTIONS]

Options:

-n, --dry-run

Show what would change without changing anything

-y, --yes

Skip the confirmation prompt

-h, --help

Print help

MISE BOOTSTRAP MISE-SHELL-ACTIVATE STATUS

Show the state of the configured shell activation

Usage: mise bootstrap mise-shell-activate status [OPTIONS]

Options:

-J, --json

Output in JSON format

--missing

Exit with status 1 if any shell activation differs from the config (all are still listed)

-h, --help

Print help

MISE BOOTSTRAP PACKAGES

Manage packages from `[bootstrap.packages]`

Declare packages as `"manager:package" = "version"`. `apply` installs what is missing and removes what is declared absent, `use` adds an entry and installs it, and `upgrade` updates configured packages that are installed. `prune` uninstalls Homebrew formulae, casks, or package plugin packages that no config declares. `import` records installed Homebrew formulae, and `status` shows what differs from the config. See https://mise.jdx.dev/bootstrap/packages/ for each package manager.

Usage: mise bootstrap packages [OPTIONS] <COMMAND>

Options:

-h, --help

Print help

MISE BOOTSTRAP PACKAGES APPLY

Install or remove packages to match `[bootstrap.packages]`

Installs each configured package that is missing or does not match its declared version, and removes packages declared `state = "absent"` on the managers that support removal (pacman, scoop, snap, and zypper). On other managers, an installed package declared absent is left in place with a warning; `apply` fails for it only when you pass `--manager` or name the package. Built-in managers may use sudo when not running as root (see the `system_packages.sudo` setting); package plugins never do. Managers that are not available on this machine are skipped.

Name packages as `manager:package`, for example `apt:curl` or `brew:jq`, to install them without adding them to config; use `mise bootstrap packages use` to record them as well. When you name packages or pass `--manager`, an unavailable manager is an error instead of a skip.

Usage: mise bootstrap packages apply [OPTIONS] [<PACKAGE>] ...

Options:

-m, --manager <MANAGER>

Only apply packages for this built-in or plugin manager

-n, --dry-run

Show what would change without changing anything

-y, --yes

Skip the confirmation prompt

--update

Refresh package manager metadata first, where the manager supports it

For example, apt runs `apt-get update` and dnf adds `--refresh`. brew, brew-cask, flatpak, flatpak-user, macos-app, mas, and snap ignore this flag.

-h, --help

Print help Arguments:

<PACKAGE>

Packages as `manager:package`; defaults to every package in `[bootstrap.packages]` Examples:

Install missing packages and remove ones declared absent

Show what would change

Apply only apt packages, without a prompt

On Debian or Ubuntu, install one package without adding it to config

On macOS, install a formula and a cask without adding them to config

MISE BOOTSTRAP PACKAGES BREW

Manage Homebrew tap URLs in `[bootstrap.brew.taps]`

mise finds a third-party tap such as `acme/tools` at `https://github.com/acme/homebrew-tools` without an entry. Add one only when the tap's repository lives at a different GitHub URL; only GitHub taps are supported. These commands edit config; they do not run Homebrew.

Not available on Windows.

Usage: mise bootstrap packages brew [OPTIONS] <COMMAND>

Options:

-h, --help

Print help

MISE BOOTSTRAP PACKAGES BREW TAP

Add a Homebrew tap URL to the global `[bootstrap.brew.taps]`

Usage: mise bootstrap packages brew tap [OPTIONS] <TAP> [<URL>]

Options:

-l, --local

Write to the local config instead of the global config

-n, --dry-run

Show the config change without writing it

-p, --path, --file <PATH>

Write to this config file or directory

-h, --help

Print help Arguments:

<TAP>

Tap name, e.g. `owner/repo`

<URL>

GitHub URL of the tap; defaults to `https://github.com/<owner>/homebrew-<repo>.git` Examples:

Record a tap whose repository is not acme/homebrew-tools

Write the entry to the local config instead

MISE BOOTSTRAP PACKAGES BREW UNTAP

Remove Homebrew tap URLs from `[bootstrap.brew.taps]`

Usage: mise bootstrap packages brew untap [OPTIONS] <TAPS> ...

Options:

-l, --local

Write to the local config instead of the global config

-n, --dry-run

Show the config change without writing it

-p, --path, --file <PATH>

Write to this config file or directory

-h, --help

Print help Arguments:

<TAPS>

Tap names, e.g. `owner/repo` Examples:

Remove a tap entry from the global config

MISE BOOTSTRAP PACKAGES EXPORT

Print the configured `nix:` packages as a NixOS module

Prints a module that adds each package to `environment.systemPackages`, without running Nix. Import it into a NixOS configuration; packages resolve against that configuration's `pkgs`. Entries for another OS or environment, and entries with `state = "absent"`, are left out. Only shorthand attributes such as `nix:ripgrep` can be exported: a flake reference or a version pin is an error, because the importing configuration decides where packages come from.

Usage: mise bootstrap packages export [OPTIONS]

Options:

--format <FORMAT>

Output format

-h, --help

Print help Examples:

Write the module to a file you can import from a NixOS configuration

MISE BOOTSTRAP PACKAGES IMPORT

Record installed Homebrew formulae in `[bootstrap.packages]`

Adds a `brew:` entry for each linked formula you installed yourself, skipping formulae that were installed only as dependencies; `--all` includes those too. Formulae from third-party taps are written with their full name, and each tap gets a `[bootstrap.brew.taps]` entry with the URL already in your config or the default GitHub URL. Writes the local config unless you pass `-g`, `-e`, or `-p`.

Usage: mise bootstrap packages import [OPTIONS]

Options:

-e, --env <ENV>

Write to the config file for this environment (mise.<ENV>.toml)

-g, --global

Write to the global config (~/.config/mise/config.toml)

New entries go to the `write_targets.packages` file when that setting is set.

-m, --manager <MANAGER>

Package manager to import from

Default: brew

--all

Import every linked formula, including dependencies

-n, --dry-run

Show the entries that would be written without writing them

-p, --path, --file <PATH>

Write to this config file or directory

-h, --help

Print help Examples:

Show the entries that would be written

Write them to the local config

Include formulae installed as dependencies

Write to the global config

MISE BOOTSTRAP PACKAGES PRUNE

Uninstall packages that no config declares

For `brew` (the default), removes every linked formula that is neither declared nor needed by a declared formula or cask, including formulae you installed with Homebrew itself. Run with `--dry-run` first, or record existing formulae with `mise bootstrap packages import`.

For `brew-cask`, removes only casks mise installed and can prove are unchanged. For a package plugin that supports uninstalling, removes only packages mise installed. A package is kept while the current config, or any trusted config mise has tracked, still declares it.

Usage: mise bootstrap packages prune [OPTIONS]

Options:

-m, --manager <MANAGER>

Package manager to prune: `brew`, `brew-cask`, or a package plugin

Default: brew

-n, --dry-run

Show what would be removed without removing anything

-y, --yes

Skip the confirmation prompt

--force

Remove `brew-cask` casks that mise installed even when it cannot prove they are unchanged, such as self-updating apps or casks with install scripts

mise removes the files it recorded installing that are still in place, but not what a cask's own install scripts created.

-h, --help

Print help Examples:

Preview which Homebrew formulae would be removed

Remove them without a prompt

Preview which casks would be removed

Preview removals for a package plugin named vscode

MISE BOOTSTRAP PACKAGES STATUS

Show the state of packages from `[bootstrap.packages]`

Usage: mise bootstrap packages status [OPTIONS]

Options:

-J, --json

Output in JSON format

--missing

Exit with status 1 if any package differs from the config (all are still listed)

-h, --help

Print help Examples:

List every configured package and its state

Print the state as JSON

Exit with status 1 if any package differs from the config

MISE BOOTSTRAP PACKAGES UPGRADE

Upgrade installed packages from `[bootstrap.packages]`

Refreshes package manager metadata, then upgrades the configured packages that are already installed. Each manager decides which version is current. Version pins in config are honored where the manager can install them; other pinned entries are skipped with a warning. Packages that are not installed yet are skipped; install them with `mise bootstrap packages apply`. See https://mise.jdx.dev/bootstrap/packages/ for what each manager does.

Name packages as `manager:package` to upgrade only those.

Usage: mise bootstrap packages upgrade [OPTIONS] [<PACKAGE>] ...

Options:

-m, --manager <MANAGER>

Only upgrade packages for this built-in or plugin manager

-n, --dry-run

Show what would change without changing anything

-y, --yes

Skip the confirmation prompt

-h, --help

Print help Arguments:

<PACKAGE>

Packages as `manager:package`; defaults to every package in `[bootstrap.packages]` Examples:

Show what would be upgraded

Upgrade every configured package that is already installed

Upgrade only apt packages, without a prompt

Upgrade one Homebrew formula

MISE BOOTSTRAP PACKAGES USE

Add packages to `[bootstrap.packages]` and install them

Like `mise use` for tools: writes a `"manager:package" = "version"` entry to the local mise.toml (or the global config with `-g`), then installs anything missing. If the manager is not available on this machine, such as `apt:` on macOS, the entry is written without installing.

Pin a version with `@`, as in `apt:[email protected]`; without `@`, or with `@latest`, the entry is `"latest"`. Homebrew puts versions in formula and cask names (`brew:postgresql@17`, `brew-cask:temurin@17`), so there `@` is part of the name. mas takes numeric App Store IDs and nix takes attribute paths or flake references, so neither accepts `@version`. aur, flatpak, flatpak-user, pacman, and snap accept `@version` but cannot install a pin, so installing skips those entries with a warning.

Usage: mise bootstrap packages use [OPTIONS] <PACKAGE> ...

Options:

-e, --env <ENV>

Write to the config file for this environment (mise.<ENV>.toml)

-g, --global

Write to the global config (~/.config/mise/config.toml) instead of the local one

New entries go to the `write_targets.packages` file when that setting is set.

-n, --dry-run

Show what would change without writing config or installing

-p, --path, --file <PATH>

Write to this config file or directory

-y, --yes

Skip the confirmation prompt

--no-install

Write the package declarations without checking or installing packages

-h, --help

Print help Arguments:

<PACKAGE>

Packages in `manager:package[@version]` form Examples:

Declare apt and winget packages; each machine installs the ones it can

On macOS, add a formula and a cask

Add a versioned Homebrew formula to the global config

Pin an apt package to a version

MISE BOOTSTRAP PACKAGES WHERE

Print the `opt` path of an installed Homebrew formula

Prints a path such as /opt/homebrew/opt/openssl@3 that keeps pointing at the installed version across upgrades. Name the formula as `brew:<formula>` or `brew:<owner>/<tap>/<formula>`, using its installed name; aliases are not resolved, and a tap-qualified name matches by formula name only. The command does not read mise config files, so only environment variables and global flags apply. If the formula is not installed, it prints nothing and exits with a nonzero status. Works on macOS on Apple silicon and on Linux (x86_64 and arm64).

Usage: mise bootstrap packages where [OPTIONS] <PACKAGE>

Options:

-h, --help

Print help Arguments:

<PACKAGE>

Formula to locate, as `brew:<formula>` or `brew:<owner>/<tap>/<formula>` Examples:

Put a formula's bin directory on PATH when it is installed

MISE BOOTSTRAP PLAN

Show what applying bootstrap resources would change

Covers accounts, packages, files and directories, system and user services, the firewall, and Compose projects, in dependency order. Repositories, dotfiles, shell activation, macOS defaults, LaunchAgents, systemd user units, the login shell, tools, hooks, and the `bootstrap` task are not planned; preview the whole run with `mise bootstrap --dry-run`.

Usage: mise bootstrap plan [OPTIONS]

Options:

-J, --json

Output a stable machine-readable plan in JSON format

--detailed-exitcode

Exit 0 if nothing would change, 2 if something would, 1 on errors or unknown state

A resource's state is unknown when mise cannot reach its declared state on its own, for example a package whose manager is not available on this machine or cannot install the pinned version, or a service whose unit does not exist.

--prompt-secrets

Prompt securely for missing bootstrap secret inputs

-h, --help

Print help Examples:

Show the planned changes

Print the plan as JSON

Exit with status 2 if anything would change

MISE BOOTSTRAP PLUGINS

Manage package manager plugins declared in `[bootstrap.plugins]`

A package plugin adds a package manager, such as one for VS Code extensions, that `[bootstrap.packages]` entries can use. `mise bootstrap` installs plugins before packages; when you run the narrower commands, run `plugins apply` before `packages apply`. Installing a plugin does not install its packages.

Usage: mise bootstrap plugins [OPTIONS] <COMMAND>

Options:

-h, --help

Print help

MISE BOOTSTRAP PLUGINS APPLY

Install package manager plugins declared in `[bootstrap.plugins]`

It does not ask for confirmation.

Usage: mise bootstrap plugins apply [OPTIONS]

Options:

-n, --dry-run

Show which plugins would be installed without installing them

-h, --help

Print help

MISE BOOTSTRAP PLUGINS STATUS

Show whether declared package manager plugins are installed

Usage: mise bootstrap plugins status [OPTIONS]

Options:

--missing

Exit with status 1 if a declared plugin is not installed

-h, --help

Print help

MISE BOOTSTRAP REMOTE

Bootstrap one or more machines over SSH

Packs a local project directory, copies it to each target, stages mise there, and runs `mise bootstrap`. The directory is `--source`. Without it, an inventory host uses its own `source`, then the one in `[bootstrap.remote]`, then the current directory; a `--host` target uses the current directory. Pick targets by name, `--tag`, or `--all` from `[bootstrap.remote.hosts]`, or give any SSH destination with `--host`.

Targets need a POSIX shell plus `tar`, `mktemp`, `cksum`, and `uname`; Windows targets are not supported. `--dry-run` still connects, uploads, and inspects each target, but changes nothing there. With `--adopt`, each target adopts the repository as `mise bootstrap --adopt` does, instead of receiving a project directory.

The `--github-relay-*` flags let targets read private GitHub repositories through this machine's credentials for the length of the run, without copying a token to them. See https://mise.jdx.dev/bootstrap/github-relay.html.

Usage: mise bootstrap remote [OPTIONS] [<TARGET>] ...

Options:

--adopt <GIT_URL|OWNER/REPO>

Adopt global configuration or shared dotfile history on each target

--all

Select every inventory host

--bootstrap-command <COMMAND>

Shell command, run on each target, that installs mise and puts it on PATH

--connect-timeout <SECONDS>

SSH connection timeout in seconds

Default: 10

--copy-link <PATH>

Copy the target of this source-relative symbolic link instead of the link; repeat for more

--copy-links

Copy the targets of every symbolic link in the source instead of the links

--exclude <PATTERN>

Another pattern to leave out of the archive; repeat for more

--fail-fast

Stop after the first failed target

--force-dotfiles

Overwrite files on each target that conflict with whole-file dotfile entries

--host <[USER@]HOST>

SSH destination that is not in the inventory (`[user@]host`); repeat for more

-i, --identity-file <PATH>

SSH identity file, overriding the inventory and SSH config

-n, --dry-run

Show what would change on each target without changing it

It still connects to each target, uploads the project, stages mise, and inspects the target.

--install-mise <PATH>

Install the provisioned mise on each host instead of only staging it

Defaults to `~/.local/bin/mise`; pass `--install-mise=<PATH>` for another path.

--keep-staging

Keep the remote staging directory for debugging

--mise-bin <PATH>

Upload this local mise executable, for platforms without an official release binary

--no-install-mise

Do not install mise on the host, even when the selected hosts configure it

--only <PART>

Run only these parts on each target

Repeat the flag or separate parts with commas. Cannot be combined with `--skip`.

--port <PORT>

SSH port, overriding the inventory and SSH config

--prompt-secrets

Prompt securely for missing secret inputs on the remote host

--remote-env <ENV>

Config environments to load on each target; repeat or separate with commas (for example, ci,dotfiles)

--remote-mise <COMMAND>

Existing mise executable name or path; relative paths use the staged project

--skip <PART>

Skip these parts on each target

Repeat the flag or separate parts with commas. Cannot be combined with `--only`.

--source <DIR>

Local directory to archive and send to each target

--ssh-option <OPTION>

OpenSSH `-o` option; repeat for multiple options

--tag <TAG>

Select configured hosts with this tag; repeat to match any tag

--update

Refresh package metadata and update repositories on each target

-y, --yes

Skip confirmation prompts on each target

--github-relay-read-only

Borrow read-only GitHub access for this run (Linux and macOS only)

Needs exactly one of `--github-relay-repo` or `--github-relay-all-repos`.

--github-relay-repo <OWNER/REPO>

Repository the targets may read through the relay; repeat for more (needs `--github-relay-read-only`)

--github-relay-all-repos

Let targets read every repository your local credentials can read (needs `--github-relay-read-only`)

--github-relay-log-requests

Log sanitized relay requests on local stderr (needs `--github-relay-read-only`)

--github-relay-no-log-requests

Turn off request logging, overriding the `github_relay` settings (needs `--github-relay-read-only`)

--github-relay-log-format <FORMAT>

Relay log and summary format, `text` or `jsonl` (needs `--github-relay-read-only`)

--github-relay-max-duration <DURATION>

End borrowed access after a duration such as `1h`; `0s` lasts the whole run (needs `--github-relay-read-only`)

-h, --help

Print help Arguments:

<TARGET>

Inventory host names from `[bootstrap.remote.hosts]` Examples:

Preview a run on a host that is not in the inventory

Bootstrap one inventory host

Bootstrap every inventory host tagged canary, without prompts

Bootstrap every inventory host and stop at the first failure

Leave mise installed on the host after the run

Let the host read one private GitHub repository during the run

MISE BOOTSTRAP REPOS

Manage Git repositories from `[bootstrap.repos]`

A repository with uncommitted changes, a different origin, or something other than a Git checkout at its path stops `apply` and `update` before anything changes. Pass `--skip-dirty` to skip repositories with uncommitted changes and continue with the rest.

Usage: mise bootstrap repos [OPTIONS] <COMMAND>

Options:

-h, --help

Print help

MISE BOOTSTRAP REPOS APPLY

Clone missing Git repositories and check out configured refs

Usage: mise bootstrap repos apply [OPTIONS]

Options:

-n, --dry-run

Show what would change without changing anything

-y, --yes

Skip the confirmation prompt

--skip-dirty

Skip repositories with local changes instead of failing

-h, --help

Print help

MISE BOOTSTRAP REPOS EXEC

Run a command in each configured Git repository

Put the command and its arguments after `--`. Paths before `--` select repositories. The command runs directly, without a shell, so pipes and `&&` do not work. Missing or conflicting repositories are skipped with a warning. Use `--continue-on-error` to visit the rest after a failure.

Usage: mise bootstrap repos exec [OPTIONS] [<PATH>] ... <COMMAND> ...

Options:

-c, --continue-on-error

Continue running in other repositories after a command fails

-n, --dry-run

Print the commands that would run without running them

-h, --help

Print help Arguments:

<PATH>

Run only in repositories at these paths, as written in config or expanded

<COMMAND>

Command and arguments to run in each repository Examples:

Show uncommitted changes in every repository

Run a command in one repository

Fetch every repository, even after one fails

MISE BOOTSTRAP REPOS STATUS

Show the state of Git repositories from `[bootstrap.repos]`

Usage: mise bootstrap repos status [OPTIONS]

Options:

-J, --json

Output in JSON format

--missing

Exit with status 1 if any repository differs from the config (all are still listed)

-h, --help

Print help

MISE BOOTSTRAP REPOS UPDATE

Clone missing Git repositories and fast-forward the rest

For a repository without a `ref`, fetches and fast-forwards the current branch; one with a detached HEAD is skipped with a warning. A repository with a `ref` is checked out at that ref.

Usage: mise bootstrap repos update [OPTIONS] [<PATH>] ...

Options:

-n, --dry-run

Show what would change without changing anything

-y, --yes

Skip the confirmation prompt

--skip-dirty

Skip repositories with local changes instead of failing

-h, --help

Print help Arguments:

<PATH>

Only update repositories at these paths, as written in config or expanded (for example ~/src/mise) Examples:

Show the Git commands that would run

Update one repository

MISE BOOTSTRAP SECRETS

Inspect bootstrap secret inputs without revealing their values

Secret inputs are values declared in `[bootstrap.secrets]` that file and dotfile templates read with `secret()`. mise reads them from environment variables, or prompts for missing ones with `--prompt-secrets`.

Usage: mise bootstrap secrets [OPTIONS] <COMMAND>

Options:

-h, --help

Print help

MISE BOOTSTRAP SECRETS STATUS

Show whether declared bootstrap secret inputs are available

Usage: mise bootstrap secrets status [OPTIONS]

Options:

-J, --json

Output in JSON format

--missing

Exit with status 1 if a declared secret input is unset, empty, or not valid Unicode

-h, --help

Print help

MISE BOOTSTRAP SERVICES

Manage services from `[bootstrap.services]`

System-scope entries, the default for entries without `builtin`, start, stop, enable, disable, or mask systemd units that already exist on Linux. User-scope entries (`scope = "user"`, or any `builtin` service) define a service for the current user on every platform: a systemd user unit on Linux, a LaunchAgent on macOS, or a Scheduled Task on Windows. For options that only one platform has, see `mise bootstrap linux systemd-units` and `mise bootstrap macos launchd-agents`.

Usage: mise bootstrap services [OPTIONS] <COMMAND>

Options:

-h, --help

Print help Examples:

Show the state of every declared service

Show what would change

Uninstall a user service

MISE BOOTSTRAP SERVICES APPLY

Apply the service state declared in `[bootstrap.services]`

Usage: mise bootstrap services apply [OPTIONS]

Options:

-n, --dry-run

Show what would change without changing anything

-y, --yes

Skip the confirmation prompt

-h, --help

Print help

MISE BOOTSTRAP SERVICES REMOVE

Uninstall a user-scope service

Removing a user-scope entry from config does not uninstall its systemd unit, LaunchAgent, or Scheduled Task. Use this command to uninstall it, whether or not it is still declared. If the entry is still declared, the next `mise bootstrap` installs it again.

It removes the dev.mise.NAME.service unit or dev.mise.NAME.plist agent, so it also removes one that [bootstrap.linux.systemd.units] or [bootstrap.macos.launchd.agents] wrote under that name. It does not remove .timer units.

Usage: mise bootstrap services remove [OPTIONS] <NAME>

Options:

-n, --dry-run

Show what would be removed without removing it

-h, --help

Print help Arguments:

<NAME>

Name of the installed user service Examples:

Preview uninstalling the user service named mise-history

MISE BOOTSTRAP SERVICES STATUS

Show the state of services from `[bootstrap.services]`

Usage: mise bootstrap services status [OPTIONS]

Options:

-J, --json

Output in JSON format

--missing

Exit with status 1 if any service differs from the config (all are still listed)

-h, --help

Print help

MISE BOOTSTRAP STATUS

Show the state of every configured bootstrap part

Lists secret inputs, packages, accounts, files and directories, services, the firewall, Compose projects, repositories, dotfiles, shell activation, macOS defaults, LaunchAgents, systemd user units, the login shell, `[tools]`, and the system dependencies of those tools, without changing anything. Checking dotfiles can render trusted templates, which may run `exec()`.

`--missing` exits with status 1 if anything differs from the config; it still lists every entry.

Usage: mise bootstrap status [OPTIONS]

Options:

-J, --json

Output in JSON format

--missing

Exit with status 1 if anything differs from the config (all entries are still listed)

--prompt-secrets

Prompt securely for missing bootstrap secret inputs

-h, --help

Print help Examples:

List every configured part and its state

Exit with status 1 if anything differs from the config

Print the state as JSON

MISE BOOTSTRAP UNAPPLY

Remove what a config environment's bootstrap sections created

Removes the files, directories, user services, systemd user units, and dotfile entries and edits that the named environments declare. Each named environment's config is loaded for this command even when `-E` or `MISE_ENV` does not select it.

mise plans the removal from the current config, not from a record of past runs, so keep the environment's config files until cleanup is done. Anything another selected config still declares is kept, and so is anything changed since it was applied unless you pass `--force`. A directory is removed only if it is empty afterward. Dotfile sources and config entries are left in place.

It asks before removing anything unless `--yes`, `MISE_YES`, or the `yes` setting is set, and fails when there is no terminal to ask. mise turns on the `yes` setting when `CI` is set.

Packages, repositories, and Compose projects are not removed; the output says how to clean them up. Accounts, system services, the firewall, and other sections are left alone.

Usage: mise bootstrap unapply [OPTIONS] <ENV> ...

Options:

-f, --force

Remove targets that changed since they were applied

-n, --dry-run

Show what would be removed without removing anything

-y, --yes

Skip the confirmation prompt

--prompt-secrets

Prompt securely for missing bootstrap secret inputs

-h, --help

Print help Arguments:

<ENV>

Config environments whose resources should be removed Examples:

Preview what removing the `ssh` environment's resources would do

Remove them after a confirmation prompt

Remove the resources of two environments without a prompt

MISE BOOTSTRAP USER

Manage your login shell from `[bootstrap.user]`

Run it as the user whose shell should change. The new shell applies to future logins, not to the shell running this command.

Usage: mise bootstrap user [OPTIONS] <COMMAND>

Options:

-h, --help

Print help

MISE BOOTSTRAP USER APPLY

Set your login shell from `[bootstrap.user]`

Usage: mise bootstrap user apply [OPTIONS]

Options:

-n, --dry-run

Show what would change without changing anything

-y, --yes

Skip the confirmation prompt

-h, --help

Print help

MISE BOOTSTRAP USER STATUS

Show whether your login shell matches `[bootstrap.user]`

Usage: mise bootstrap user status [OPTIONS]

Options:

-J, --json

Output in JSON format

--missing

Exit with status 1 if your login shell differs from the config

-h, --help

Print help

MISE CACHE

Manage the mise cache

The cache holds data mise can fetch or rebuild again, such as version lists and release metadata. With no subcommand, prints the cache directory, like `mise cache path`. See https://mise.jdx.dev/cache-behavior.html.

Usage: mise cache [OPTIONS] [COMMAND]

Options:

-h, --help

Print help

MISE CACHE CLEAR

Delete cached data

With no arguments, deletes the whole cache directory, the cached environment, and every task's cached artifacts. With TOOL arguments, deletes only the cached data of those tools, such as their version lists. With --task, deletes only that task's cached artifacts. Installed tools are not removed; mise downloads or rebuilds what it needs again.

Usage: mise cache clear [OPTIONS] [<TOOL>] ...

Options:

--outdate

Mark all cache files as old

--task <TASK>

[experimental] Clear task artifact cache entries for a task name or pattern

-h, --help

Print help Arguments:

<TOOL>

Only clear the cache of these tools, such as `node` Examples:

Clear the whole cache

Refresh node's version list

[experimental] Forget the build task's cached artifacts

MISE CACHE PATH

Print the cache directory path

Usage: mise cache path [OPTIONS]

Options:

-h, --help

Print help

MISE CACHE PRUNE

Remove cache files that have not been accessed recently

Removes cache files not accessed within the `cache_prune_age` setting. Set it to `0s` to keep cache files indefinitely. mise also prunes the cache now and then on its own.

Usage: mise cache prune [OPTIONS] [<TOOL>] ...

Options:

-v, --verbose

Show pruned files

--dry-run

Show what would be pruned without deleting anything

-h, --help

Print help Arguments:

<TOOL>

Only prune the cache of these tools, such as `node` Examples:

List what would be removed

MISE CACHE TASK

[experimental] Inspect artifact cache entries for a task

Lists the artifact cache entries of the tasks matching TASK with their key, size, run time, last access, and outputs, and marks the entry that matches the task's current inputs. Remove entries with `mise cache clear --task TASK`. See https://mise.jdx.dev/tasks/caching.html#enable-artifact-caching.

Usage: mise cache task [OPTIONS] <TASK>

Options:

-J, --json

Output in JSON format

-h, --help

Print help Arguments:

<TASK>

Task name or pattern to inspect Examples:

List the build task's cache entries

MISE COMPLETION

Generate shell completions

Prints a completion script for SHELL, or with --install writes it where that shell loads completions from. The script asks mise for candidates as you type, so it also completes your project's task names and tool versions. See https://mise.jdx.dev/shell-setup.html#autocompletion.

Usage: mise completion [OPTIONS] [<SHELL>]

Options:

-s, --shell <SHELL>

Shell type to generate completions for

--include-bash-completion-lib

No longer has any effect; kept so older setup scripts keep working

--usage

No longer has any effect; kept so older setup scripts keep working

--install

Install the script where this shell looks for it, instead of printing it

It writes only the script file, never a shell startup file or PowerShell profile. If your shell needs a one-time setup line, such as zsh's `fpath+=` or PowerShell's dot-source, mise prints it for you to add.

--force

Replace a file at the target path that mise did not write

--tool <TOOL>

Generate completions for a tool installed with the `packslip:` backend

TOOL is the tool or one of its executables; with --install, pass the executable's name. The script matches the version active in the current directory and comes from the most verifiable source its packslip offers: a file the vendor shipped, a script derived from its CLI spec, or a command of the tool's own. With --install, mise writes a small stub that asks mise for the script each time the shell completes the tool, so it follows version changes without being rewritten.

-h, --help

Print help Arguments:

<SHELL>

Shell type to generate completions for (required) Examples:

Install completions for zsh; bash, fish, and powershell work the same way

Print the script to inspect it or save it somewhere else

Install completions for hk, a tool installed with the packslip backend

MISE CONFIG

Manage config files

With no subcommand, lists the config files mise loads, from lowest to highest precedence, like `mise config ls`; the flags below apply to that listing.

Usage: mise config [OPTIONS] [COMMAND]

Options:

--truncate

Truncate long terminal output to fit the available width

Default: true

-J, --json

Output in JSON format

--no-header

Do not print the table header

--tracked-configs

List every config file mise has loaded, in any project

mise remembers the config files it loads so `mise prune` keeps the versions they use.

-h, --help

Print help

MISE CONFIG EXPLAIN

Describe each key in a mise TOML file

Lists every key the file sets, with its line and what it does, from the same schema editors use to check a config. A key mise does not read is marked, with the known key it most likely meant, and so is a deprecated one. Reads the highest-precedence loaded TOML file by default; select another with `--file`, `--global`, or `--system`.

Usage: mise config explain [OPTIONS] [<KEY>]

Options:

-f, --file, --path <FILE>

Config file to read, or a directory whose config file to read

Defaults to the highest-precedence loaded TOML file other than the global override files.

-g, --global

Read the global config file

--system

Read the system config file

--override

Read the global override file, `config.override.toml`

-J, --json

Print the keys as JSON

-h, --help

Print help Arguments:

<KEY>

Dotted key path to describe, with the keys under it; omit for the whole file

Quote a key with a dot in its name as TOML does, inside shell quotes: `'tasks."build.sh"'`. Unquoted, `tasks.build.sh` still finds the task `build.sh` when there is no key `build` in the way. Examples:

Describe the keys of the project config

Describe only the keys under [tasks]

MISE CONFIG GET

Print a value from one mise TOML file

Reads the highest-precedence loaded TOML file by default. Select another with `--file`, `--global`, or `--system`. This reads stored values, not the merged or template-expanded environment; use `mise env` for the resolved environment.

Usage: mise config get [OPTIONS] [<KEY>]

Options:

-f, --file, --path <FILE>

Config file to read, or a directory whose config file to read

For a directory, mise reads the TOML config file already there, such as `.mise.toml`, or `mise.toml` when there is none. Defaults to the highest-precedence loaded TOML file other than the global override files.

-g, --global

Read the global config file

--system

Read the system config file

--override

Read the global override file, `config.override.toml`

-h, --help

Print help Arguments:

<KEY>

Dotted key path to print, such as `tools.python`; omit to print the whole file

Quote a key with a dot in its name as TOML does, inside shell quotes: `'tasks."build.sh"'`. Unquoted, `tasks.build.sh` still finds the task `build.sh` when there is no key `build` in the way. Examples:

Print the python request

Print the whole file

MISE CONFIG LS

List config files currently in use, from lowest to highest precedence

Later files override earlier ones. Global override files (`config.override.toml`) rank above all project config and are labeled `override`.

Usage: mise config ls [OPTIONS]

Options:

--truncate

Truncate long terminal output to fit the available width

Default: true

-J, --json

Output in JSON format

--no-header

Do not print the table header

--tracked-configs

List every config file mise has loaded, in any project

mise remembers the config files it loads so `mise prune` keeps the versions they use.

-h, --help

Print help Examples:

List the loaded config files and the tools each one requests

MISE CONFIG SET

Set a value in one mise TOML file

Edits the highest-precedence loaded TOML file by default, which may be an environment-specific override. Use `--file` to select an existing project file, or `--global`/`--system` to edit or create those config files.

This edits configuration without installing tools. Use `mise use` to install and select a version together. For environment variables and settings, `mise set` and `mise settings set` are shorter, but they choose their file differently: `mise set` writes the nearest `mise.toml`, and `mise settings set` writes the global config unless you pass `--local`.

Known settings use their declared type; boolean settings accept `true`, `false`, `yes`, `no`, `1`, and `0`. For other keys, `true` and `false` become booleans and every other value is stored as a string. Use `--type bool` to store `yes`, `no`, `1` or `0` as a boolean, `--type string` to store `true` or `false` as text, and `--type integer` for a number.

Usage: mise config set [OPTIONS] <KEY> [<VALUE>]

Options:

-f, --file, --path <FILE>

Config file to edit, or a directory whose config file to edit

For a directory, mise edits the TOML config file already there, such as `.mise.toml`, or `mise.toml` when there is none. Defaults to the highest-precedence loaded TOML file other than the global override files.

-g, --global

Edit the global config file

--override

Edit the global override file, `config.override.toml`

--system

Edit the system config file

--append

Append the value to a list without duplicating an existing entry

--remove

Remove the value from an existing list

-t, --type <TYPE>

TOML type to store the value as; inferred from the value by default

Default: infer

-h, --help

Print help Arguments:

<KEY>

Dotted key path to set, such as `tools.python`

Quote a key with a dot in its name as TOML does, inside shell quotes: `'tasks."build.sh"'`. Unquoted, `tasks.build.sh` still finds the task `build.sh` when there is no key `build` in the way.

<VALUE>

The value to set the key to (optional if provided as KEY=VALUE) Examples:

Request python 3.13

Set an environment variable

Settings get their declared type, here an integer

List settings take comma-separated values

Add a PATH entry unless it is already there

Remove that PATH entry

Edit the global config

MISE DEACTIVATE

Print the script to disable mise in the current shell session

In a shell where mise is activated, run `mise deactivate`: the activation function evaluates the script for you. Calling the executable directly (`command mise deactivate`) only prints the script, so evaluate it yourself as in the examples below. New shells still activate mise; remove the line from your shell startup file to stop that.

Usage: mise deactivate [OPTIONS]

Options:

-h, --help

Print help Examples:

Turn mise off in an activated shell

Bash or Zsh, calling the executable rather than the activation function

Fish, calling the executable rather than the activation function

MISE DAEMONS

[experimental] Manage project daemons with pitchfork

Declare long-running processes in `[daemons]`, either as commands or as service presets such as `postgres` and `redis`, and mise runs them under pitchfork with the project's tools and environment. Requires `experimental = true`.

With no subcommand, lists the project's daemons like `mise daemons ls`.

See https://mise.jdx.dev/daemons.html

Usage: mise daemons [OPTIONS] [COMMAND]

Options:

--json

Output in JSON format, including ports, URLs, and data directories

-h, --help

Print help Examples:

Start the default group, or every project daemon

Show the last 50 lines of api's output

Stop every registered project daemon

MISE DAEMONS PROVIDERS

[experimental] Manage shared servers from global `[daemon_providers]`

A shared server is one PostgreSQL, CockroachDB, or NATS server declared in your global config, with a separate database or account for each checkout that uses it. Not supported on Windows. See https://mise.jdx.dev/daemons/sharing.html#shared-server-providers

Usage: mise daemons providers [OPTIONS] [COMMAND]

Options:

-h, --help

Print help Examples:

List shared servers

Start the shared server named local-postgres

MISE DAEMONS PROVIDERS LS

[experimental] List shared servers

Usage: mise daemons providers ls [OPTIONS]

Options:

--json

Output in JSON format

-h, --help

Print help

MISE DAEMONS PROVIDERS START

[experimental] Start shared servers

Usage: mise daemons providers start [OPTIONS] [<NAMES>] ...

Options:

-h, --help

Print help

MISE DAEMONS PROVIDERS STOP

[experimental] Stop shared servers (data is kept)

Usage: mise daemons providers stop [OPTIONS] [<NAMES>] ...

Options:

-h, --help

Print help

MISE DAEMONS PROVIDERS RESTART

[experimental] Restart shared servers with their current configuration

Usage: mise daemons providers restart [OPTIONS] [<NAMES>] ...

Options:

-h, --help

Print help

MISE DAEMONS START

[experimental] Start project daemons and the daemons they depend on

Installs missing tools and registers the project's daemons with pitchfork, then starts the selected daemons and waits until they are ready. With no names, starts the `default` group from `[daemon_groups]` when the project declares one, otherwise every project daemon.

Select daemons by name (`api` or a qualified ID such as `shop/api`), by group with `--group NAME`, or all of them with `--all`. `--all` covers every daemon in this project, including those the `default` group leaves out; unlike pitchfork's own `--all`, it never reaches other projects, and it cannot be combined with names or `--group`. Other flags pass through to `pitchfork start`.

Usage: mise daemons start [OPTIONS] [<ARGS>] ...

Options:

-h, --help

Print help Arguments:

<ARGS>

Daemon names (short, such as `api`, or qualified, such as `shop/api`), `--group NAME`, and flags passed to pitchfork Examples:

Start the default group, or every daemon

Start api and the daemons it depends on

Start a group declared in [daemon_groups]

MISE DAEMONS REGISTER

[experimental] Register project daemons for on-demand startup

Installs missing tools, validates daemon definitions and dependencies, and registers the generated configuration with pitchfork without starting anything. Covers every project daemon, including imported dependencies and daemons outside the `default` group. Daemons that are already running keep running.

A running pitchfork supervisor with its proxy enabled can then start a registered HTTP daemon when a request reaches its hostname. See https://mise.jdx.dev/daemons/worktrees.html#register-for-on-demand-startup

Usage: mise daemons register [OPTIONS]

Options:

-h, --help

Print help Examples:

Register every project daemon

MISE DAEMONS STOP

[experimental] Stop project daemons

With no names, stops every daemon the project has registered, including daemons a removed group started. Data is kept. Select daemons as `mise daemons start` does: by name, with `--group NAME`, or with `--all`. Other flags pass through to `pitchfork stop`.

Usage: mise daemons stop [OPTIONS] [<ARGS>] ...

Options:

-h, --help

Print help Arguments:

<ARGS>

Daemon names (short, such as `api`, or qualified, such as `shop/api`), `--group NAME`, and flags passed to pitchfork Examples:

Stop one daemon

MISE DAEMONS RESTART

[experimental] Restart project daemons

Installs missing tools first and selects daemons as `mise daemons start` does: with no names, the `default` group when the project declares one, otherwise every project daemon. A changed daemon declaration takes effect on restart. Other flags pass through to `pitchfork restart`.

Usage: mise daemons restart [OPTIONS] [<ARGS>] ...

Options:

-h, --help

Print help Arguments:

<ARGS>

Daemon names (short, such as `api`, or qualified, such as `shop/api`), `--group NAME`, and flags passed to pitchfork Examples:

Restart api with its current declaration

MISE DAEMONS LS

[experimental] List project daemons

Shows each daemon's ID, status, and source without starting a supervisor or registering configuration.

Usage: mise daemons ls [OPTIONS]

Options:

--json

Output in JSON format, including ports, URLs, and data directories

-h, --help

Print help Examples:

Include ports, URLs, and data directories

MISE DAEMONS URLS

[experimental] Show each daemon's URL and port

Lists every project daemon with its proxy hostname URL, the port it binds, its proxy mode, and its status. A daemon's hostname does not change when its port does, so an HTTP service can be addressed by URL while concurrent checkouts keep separate ports. A daemon with no `port`, or with `proxy = false`, gets no hostname and is listed without a URL. Each project's table is followed by its project page URL and, in a linked Git worktree, its stack page URL.

See https://mise.jdx.dev/daemons/worktrees.html#stable-urls-per-worktree

Usage: mise daemons urls [OPTIONS]

Options:

--json

Output in JSON format, including ports, URLs, and data directories

-h, --help

Print help Examples:

Show the URLs for this checkout

MISE DAEMONS LOGS

[experimental] Show the output of project daemons

Requires a running pitchfork supervisor. With no names, shows every daemon the project has registered. Flags such as `-n`, `--since`, and `--grep` pass through to `pitchfork logs`.

Usage: mise daemons logs [OPTIONS] [<ARGS>] ...

Options:

-h, --help

Print help Arguments:

<ARGS>

Daemon names (short, such as `api`, or qualified, such as `shop/api`), `--group NAME`, and flags passed to pitchfork Examples:

Show the last 50 lines of api's output

Show the last five minutes of output

MISE DAEMONS STATUS

[experimental] Show the status of project daemons

Prints pitchfork's status for each selected daemon. With no names, covers every daemon the project has registered.

Usage: mise daemons status [OPTIONS] [<ARGS>] ...

Options:

-h, --help

Print help Arguments:

<ARGS>

Daemon names (short, such as `api`, or qualified, such as `shop/api`), `--group NAME`, and flags passed to pitchfork Examples:

Show the status of api

MISE DAEMONS TUI

[experimental] Open the pitchfork dashboard

Requires a running pitchfork supervisor. Takes `pitchfork tui` flags, not daemon names.

Usage: mise daemons tui [OPTIONS] [<ARGS>] ...

Options:

-h, --help

Print help Arguments:

<ARGS>

Flags passed to `pitchfork tui`

MISE DAEMONS PRUNE

[experimental] Remove daemon state left by deleted projects

Scans `$MISE_STATE_DIR/daemons/` for state that belongs to deleted projects, including removed Git worktrees. For each one, stops its daemons, unregisters its configuration, and deletes its state and data. Existing projects are not touched.

Use `--dry-run` to preview the paths and sizes. Removal cannot be undone and asks for confirmation. Pass the global `--yes` flag to prune without a prompt; entries that may belong to an unmounted volume or a deleted symlink are then skipped and need a separate interactive confirmation.

pitchfork must be available. State is kept when mise cannot confirm that the daemons have stopped or cannot unregister their configuration.

Usage: mise daemons prune [OPTIONS]

Options:

-n, --dry-run

Show what would be removed without deleting anything

-h, --help

Print help Examples:

Preview what would be removed

Review the list and confirm removal

MISE DOTFILES

Deploy, track, and sync dotfiles

A `[dotfiles]` entry deploys a file (from a source with `symlink`, `symlink-each`, `copy`, or `template`, or from inline `content`), removes one (`mode = "absent"`), sets an existing path's `permissions`, edits part of a file, or tracks a live file where it is (`mode = "track"`). mise saves tracked files to a local Git history that you can browse and roll back, and syncs it with other machines through an origin repository. `mise dot` is a shorter alias.

Deploy files with `add`, `apply`, `diff`, `status`, and `unapply`. Track and restore files with `track`, `save`, `history`, `rollback`, and `undo`. Sync them with `origin`, `sync`, and `pull`.

See https://mise.jdx.dev/dotfiles.html and https://mise.jdx.dev/dotfiles/history.html

Usage: mise dotfiles [OPTIONS] <COMMAND>

Options:

--local

Work on this machine's local-only history (`mode = "track-local"`), which is never shared

-h, --help

Print help Examples:

Start managing ~/.zshrc from your dotfiles directory

Deploy every [dotfiles] entry

Show the state of your dotfiles and their history

Save the history of a directory in place

List saved checkpoints

MISE DOTFILES ADD

Start deploying a file, or copy its edits back to the source

For a target that is not managed yet, saves its contents as a source under `dotfiles.root` (or at the path given with `--source`), adds a `[dotfiles]` entry, and applies it unless you pass `--no-apply`. For a target that is already managed, updates its source from the live file. `--dry-run` previews the source and config changes without writing them.

A target inside the tree of a dotfile group is captured into that group's source instead, without a new `[dotfiles]` entry: the deepest group whose target contains it, or the one named with `--group`.

Usage: mise dotfiles add [OPTIONS] [<TARGET>] ...

Options:

--changed

Update the sources of every changed file managed in copy mode

-f, --force

Overwrite existing sources without prompting

-g, --global

Write to the global config (the default)

New entries go to the `write_targets.dotfiles` file when that setting is set.

-l, --local

Write to the project config instead of the global config

-m, --mode <MODE>

Mode for a target that is not managed yet: symlink, symlink-each, copy, or template (default: the `dotfiles.default_mode` setting)

A target that is already managed keeps its mode.

-n, --dry-run

Print the config and source changes without writing anything

--no-apply

Add the entry without applying it

-p, --path <PATH>

Write to this config file or directory

-s, --source <PATH>

Source path to use for a single target

A relative path starts from the current directory. The entry records it relative to the config file's directory when it lies inside it, and as an absolute path otherwise.

-y, --yes

Skip the confirmation prompt

--prompt-secrets

Prompt for `[bootstrap.secrets]` values that templates need and the environment does not set

--group <NAME>

Capture into the tree of this dotfile group

-h, --help

Print help Arguments:

<TARGET>

Targets to add or update Examples:

Start managing ~/.zshrc from your dotfiles directory

Copy the file into place instead of symlinking it

Choose where the source is stored

Capture the file into a dotfile group's tree

Copy edits of every changed copy-mode file back to its source

MISE DOTFILES APPLY

Link, copy, and render `[dotfiles]` entries into place

Applies the whole-file entries and edits that are not in their desired state. Whole-file entries symlink, copy, render templates, write inline `content`, set `permissions`, or remove targets declared `mode = "absent"`. Edit entries manage a marker-delimited block, a single line, or merged keys in a file mise does not otherwise own.

Entries that deploy mise's own configuration are applied first and the configuration is read again, so a rule the new file adds applies in the same run.

`apply` works from the files on this machine. It never fetches or pulls: to bring in changes from other machines, run `mise dot sync`, `mise dot pull`, then `mise dot apply`.

The `pre-dotfiles` and `post-dotfiles` bootstrap hooks run before and after the apply (with `--dry-run` they are printed, not run), and the matching `[history.reload]` commands run for the targets it wrote.

With `--prune`, also removes files that dotfile groups deployed but no active entry deploys now: files of a group that is no longer selected or declared, and files a group stopped deploying because of a new `exclude` or a deleted source.

Usage: mise dotfiles apply [OPTIONS] [<TARGET>] ...

Options:

-f, --force

Overwrite existing files that conflict with whole-file dotfile entries

-n, --dry-run

Print the actions that would run without writing anything

-y, --yes

Skip the confirmation prompt

--prune

Also remove files that dotfile groups deployed but no active entry deploys now

--prompt-secrets

Prompt for `[bootstrap.secrets]` values that templates need and the environment does not set

-h, --help

Print help Arguments:

<TARGET>

Only apply these targets Examples:

Deploy every entry that is out of date

Print what would change

Also remove files left by dotfile groups

Overwrite conflicting files without prompting

MISE DOTFILES CAPTURE

Run a command and save tracked files before and after it

Runs the command with your terminal and environment and saves a checkpoint before and after it, even when the command fails or changes nothing, so `mise dot undo` can reverse what it did to your tracked files. Edits you make while it runs are part of the same operation. Packages, services, and other system changes are not recorded and cannot be undone. If saving fails, mise warns and still exits with the command's status.

Usage: mise dotfiles capture [OPTIONS] <COMMAND> ...

Options:

--label <LABEL>

Describe this operation in history

-h, --help

Print help Arguments:

<COMMAND>

Command and arguments to run, after -- Examples:

Record what an upgrade changes

Label the operation in history

MISE DOTFILES CONFLICTS

Compare both sides of a sync conflict

Prints a unified diff from this machine's saved version to the version fetched from the origin. `--difftool` opens the comparison in Git's configured diff tool; when `diff.tool` is unset, Git falls back to `merge.tool`. This command changes neither side. Resolve a conflict with `mise dot pull --take-remote` or `--keep-local`.

Usage: mise dotfiles conflicts [OPTIONS] [<PATH>] ...

Options:

--difftool

Open the comparison in Git's configured diff or merge tool

--tool <TOOL>

Use this Git diff tool instead of the configured default

-h, --help

Print help Arguments:

<PATH>

Only inspect these conflicted paths Examples:

Show every conflict

Show one conflicted file

Open the comparison in Git's diff tool

Use a specific diff tool

MISE DOTFILES DIFF

Show what `mise dot apply` would change

Prints a unified diff for every whole-file entry and edit that `mise dot apply` would change. Templates are rendered first, so trusted template functions may run. Tracked entries have nothing to apply; use `mise dot history diff` to see their unsaved changes.

Usage: mise dotfiles diff [OPTIONS] [<TARGET>] ...

Options:

--prompt-secrets

Prompt for `[bootstrap.secrets]` values that templates need and the environment does not set

-h, --help

Print help Arguments:

<TARGET>

Only show these targets Examples:

Show every pending change

Show the change for one target

MISE DOTFILES EDIT

Open a dotfile's source in your editor

Opens the file that defines TARGET in `$VISUAL` or `$EDITOR`: the source for symlink, copy, and template entries; the file itself for tracked and permissions-only entries; and the declaring config for inline `content`, `absent` entries, and edits without a source file. A `fnox` entry is edited with `fnox edit --file`, which stores the change in fnox.

An unmanaged target is first added to the global `[dotfiles]`, as `mise dot add --no-apply` would add it, after a prompt that `--yes` skips. Without a terminal, an unmanaged target needs `--yes`. With `--apply`, applies the target after the editor exits.

Usage: mise dotfiles edit [OPTIONS] <TARGET>

Options:

--apply

Apply this target after the editor exits

-m, --mode <MODE>

Mode to use if the target is not managed yet: symlink, symlink-each, copy, or template (default: the `dotfiles.default_mode` setting)

-s, --source <PATH>

Source path to use if the target is not yet managed

-y, --yes

Skip the confirmation prompt when adding an unmanaged target

--group <NAME>

Dotfile group whose tree holds the target, when several groups deploy into its directory

--prompt-secrets

Prompt for `[bootstrap.secrets]` values that templates need and the environment does not set

-h, --help

Print help Arguments:

<TARGET>

Target to edit Examples:

Edit the source of ~/.zshrc

Edit the source, then deploy it

MISE DOTFILES EXCLUDE

Never save paths matching a glob

Adds a glob to `[history] exclude` in the global config. The rule applies to every tracked path. Quote the glob so your shell does not expand it.

Use exclusions for logs, caches, databases, and session state. For files you want to save only on demand, track them with `mise dot track --no-autosave` instead. To limit what one tracked directory saves, edit the `exclude` or `include` list of its `[dotfiles]` entry.

Usage: mise dotfiles exclude [OPTIONS] <GLOB>

Options:

-h, --help

Print help Arguments:

<GLOB>

A glob such as `~/.config/hypr/plugins/**` Examples:

Never save Codex session logs

MISE DOTFILES HISTORY

Browse saved versions of your tracked files

A checkpoint is a saved version of every `[dotfiles]` entry with `mode = "track"`. `mise dot save`, the watcher, and every command that changes tracked files (such as `mise bootstrap`, `mise dot apply`, `rollback`, `pull`, and `undo`) record one. Checkpoints hold file contents only, not packages or services. Files deployed in other modes are saved only if you also track them. With no subcommand, lists checkpoints newest first.

See https://mise.jdx.dev/dotfiles/history.html

Usage: mise dotfiles history [OPTIONS] [COMMAND]

Options:

-J, --json

Output in JSON format

-n, --limit <LIMIT>

Show at most this many checkpoints (0 for all)

Default: 20

--path <PATH>

Only checkpoints where this path (or something under it) changed

--trigger <TRIGGER>

Only checkpoints with this trigger, such as edit, save, agent, bootstrap, apply, rollback, or undo

`bootstrap` covers `mise bootstrap`, its `packages` commands, and `mise dot add`, `apply`, `edit`, and `unapply`. `apply` covers incoming changes written by `mise dot pull` or the watcher.

--label <LABEL>

Only checkpoints with this label

--pending

Only checkpoints recorded by operations that did not finish

-h, --help

Print help Examples:

List recent checkpoints

List checkpoints that changed one file

List the last five checkpoints from mise bootstrap or mise dot apply

Show the newest checkpoint

Show unsaved changes

MISE DOTFILES HISTORY DESCRIBE

Set the description of a checkpoint

Usage: mise dotfiles history describe [OPTIONS] <REF> <TEXT>

Options:

-h, --help

Print help Arguments:

<REF>

Numeric checkpoint ID, `latest`, `latest~N`, or `commit:<sha>`

<TEXT>

The new description Examples:

Describe the newest checkpoint

MISE DOTFILES HISTORY DIFF

Compare checkpoints, or your files against one

Without arguments, shows unsaved changes: the files on disk against the latest checkpoint. With one reference, shows what that checkpoint changed since the one before it. With two, compares them.

Usage: mise dotfiles history diff [OPTIONS] [<A>] [<B>]

Options:

--operation

Compare an operation with the checkpoint it saved before it ran

With no reference, uses the newest operation, ignoring later saves. With one reference, uses that operation. Fails if the operation's earlier checkpoint is unavailable instead of comparing an unrelated save.

-p, --patch

Print the full patch instead of a per-file summary

--path <PATH>

Restrict to one path (a file or a directory)

--exit-code

Exit 1 when the two sides differ

-h, --help

Print help Arguments:

<A>

Numeric checkpoint ID, `latest`, `latest~N`, or `commit:<sha>`

<B>

Compare `A` with this checkpoint instead of its predecessor Examples:

Show unsaved changes

Show what checkpoint 12 changed

Print the full patch between two checkpoints

Show what the newest operation changed

MISE DOTFILES HISTORY LS

List checkpoints, newest first

Usage: mise dotfiles history ls [OPTIONS]

Options:

-J, --json

Output in JSON format

-n, --limit <LIMIT>

Show at most this many checkpoints (0 for all)

Default: 20

--path <PATH>

Only checkpoints where this path (or something under it) changed

--trigger <TRIGGER>

Only checkpoints with this trigger, such as edit, save, agent, bootstrap, apply, rollback, or undo

`bootstrap` covers `mise bootstrap`, its `packages` commands, and `mise dot add`, `apply`, `edit`, and `unapply`. `apply` covers incoming changes written by `mise dot pull` or the watcher.

--label <LABEL>

Only checkpoints with this label

--pending

Only checkpoints recorded by operations that did not finish

-h, --help

Print help Examples:

List every checkpoint

List operations that did not finish

MISE DOTFILES HISTORY PURGE

Erase a path's saved versions from history

Rewrites the history without the path, for a file you tracked by mistake that holds a secret. `untrack`, `rollback`, and `undo` only add checkpoints; they leave the old versions readable.

Checkpoints that changed only this path are removed. The others stay, with their descriptions, dates, and IDs, minus the path. Without `--yes`, the command lists what would change and asks first.

mise never rewrites history that is on the origin: if a saved version of the path was ever published, the command refuses. Rotate the secret, then see https://mise.jdx.dev/dotfiles/encryption.html#remove-plaintext-from-history.

This does not stop tracking the path. If the file is still tracked, the next save records its current contents again, so run `mise dot untrack` first (or encrypt it). Stop the watcher service while this runs.

Usage: mise dotfiles history purge [OPTIONS] <PATH> ...

Options:

-n, --dry-run

Show what would change without changing anything

-y, --yes

Rewrite without prompting

--backup

Keep the replaced history in the repository under `refs/mise/purge-backup/`

The backup still holds the content you are erasing; delete it with `git update-ref -d` once you are sure.

--keep-objects

Leave the replaced objects on disk instead of deleting them

-h, --help

Print help Arguments:

<PATH>

Files or directories to erase from history Examples:

List the checkpoints that hold the file

Erase every saved version of the file

MISE DOTFILES HISTORY SHOW

Show a checkpoint: its trigger, changes, and operation journal

Prints the checkpoint's trigger, description, time, and machine, the files that changed since the previous checkpoint, and the tracked entries it covers. For a checkpoint that an operation recorded, also prints the operation's journal of the files it wrote.

Usage: mise dotfiles history show [OPTIONS] [<REF>]

Options:

-J, --json

Output in JSON format

--files

List every file in the snapshot

--path <PATH>

Resolve `latest~N` among the checkpoints where this path changed

-h, --help

Print help Arguments:

<REF>

Numeric checkpoint ID, `latest` (the default), `latest~N`, or `commit:<sha>` Examples:

Show the newest checkpoint

List every file in an older checkpoint

MISE DOTFILES INCLUDE

Stop excluding paths matching a glob

Removes a glob that `mise dot exclude` added to `[history] exclude` in the global config. Pass the pattern exactly as you excluded it. Other matching exclusion rules still apply. This command does not edit a tracked directory's `include` list; change that list in its `[dotfiles]` entry.

Usage: mise dotfiles include [OPTIONS] <GLOB>

Options:

-h, --help

Print help Arguments:

<GLOB>

The glob as written by `mise dot exclude` Examples:

Save Codex session logs again

MISE DOTFILES NOTIFY

Send a test desktop notification

Checks that `history.notify` can reach you. On macOS the first notification asks for permission, so run this once to be prompted now instead of at the first sync conflict. Fails with the reason when this build or machine cannot show notifications: a macOS build that is not mise's signed release (such as Homebrew's), a missing `notify-send` on Linux, denied permission, or `history.notify = false`.

mise notifies you only when a sync conflict pauses syncing. Other problems, such as a watcher that cannot save, appear in `mise doctor` and `mise dot status`.

Usage: mise dotfiles notify [OPTIONS]

Options:

-h, --help

Print help Examples:

Send a test notification

MISE DOTFILES ORIGIN

Show, connect, or disconnect the origin repository

The origin is a Git repository that shares the history of your tracked files with your other machines. With no subcommand, prints the connected URL, its branch, the config file that declares it, and the sync mode (the `history.sync` setting). `--remove` disconnects; local checkpoints and fetched history stay.

See https://mise.jdx.dev/dotfiles/sync.html

Usage: mise dotfiles origin [OPTIONS] [COMMAND]

Options:

--remove

Disconnect the origin by removing `[history.origin]`; local checkpoints and fetched history stay

-h, --help

Print help Examples:

Show the connected repository

Connect a repository

Disconnect the repository

MISE DOTFILES ORIGIN SET

Connect an origin repository

Use a private repository: every saved checkpoint is shared, including those saved before you connect. mise shows the sync mode and the tracked files before you confirm, then runs the first sync. It never replaces a repository that has unrelated history, and it refuses to push older plaintext versions of files you now encrypt. The connection is written to `[history.origin]` in `config.local.toml` next to your global config, so it stays on this machine.

The origin holds tracked-file history, not a checkout of your global config: connect a repository of its own, or a separate branch (`--branch`) of the one you adopt as global config with `mise bootstrap --adopt`.

Usage: mise dotfiles origin set [OPTIONS] <URL>

Options:

--branch <BRANCH>

The branch to sync (default: the repository's default branch)

Reconnecting a repository this machine already follows keeps that connection's branch. A repository with no branches gets `main`, which the first push creates.

--sync <MODE>

How to sync with the repository: sync, fetch-only, or manual

`sync` pushes saved checkpoints and applies incoming changes automatically. `fetch-only` fetches automatically and never pushes. `manual` makes no automatic network calls: `mise dot sync` pushes and fetches, and `mise dot pull` applies, only when you run them; local history is still saved automatically. When omitted, mise prompts; with `--yes`, it uses the `history.sync` setting.

-y, --yes

Skip the confirmation prompt

-h, --help

Print help Arguments:

<URL>

The repository URL (any Git URL; use a private repository) Examples:

Connect and choose a sync mode at the prompt

Connect without automatic network activity

MISE DOTFILES PATHS

List tracked paths and how they are saved

Shows each tracked entry with the config file that declares it, whether it saves automatically, and how many files it covers. Entries mise cannot save are listed as invalid, omitted, or incomplete, so you can see what is not protected.

Usage: mise dotfiles paths [OPTIONS]

Options:

-J, --json

Output in JSON format

--preview <PATH>

List the files that tracking this path would save, without tracking it

--noisy

List the paths the watcher found changing constantly and saves less often

-h, --help

Print help Examples:

List tracked paths

List the files tracking ~/.codex would save

List files the watcher saves less often

MISE DOTFILES PULL

Write fetched changes from other machines to tracked files

Writes the changes that the last `mise dot sync` fetched from your other machines. (`mise dot apply` deploys your own `[dotfiles]` entries; `pull` writes what other machines pushed.) `pull` restores tracked paths, including tracked symlinks, but never deploys `copy`, `symlink`, or `template` entries: when a tracked file is the source of one, `pull` updates the source, and `mise dot apply` then writes the target your application reads. mise saves a checkpoint first, so `mise dot undo` reverses the whole pull, and runs the matching `[history.reload]` commands after writing.

A pull applies every incoming change together, including config files and the files they reference; it does not take paths. Nothing is written if an incoming config file does not parse, a file has unsaved local edits, your own checkout has staged Git changes, or a file changed on both sides. A file that changed on both sides is a conflict: compare the two versions with `mise dot conflicts`, then resolve it with `--take-remote` or `--keep-local`, or resolve every conflict with `--take-remote-all` or `--keep-local-all`. While any conflict remains, pushing and applying stop for all tracked files; local history and fetching continue.

In `sync` mode the watcher pulls on its own when there are no conflicts. When incoming config declares more tracked files, their versions from the origin are written in the same pull.

Usage: mise dotfiles pull [OPTIONS] [<PATH>] ...

Options:

-n, --dry-run

Show the plan without changing anything

-y, --yes

Accepted for compatibility; pull skips the apply confirmation

--take-remote <PATH>

Resolve a conflict with the origin's version

--keep-local <PATH>

Resolve a conflict by keeping this machine's version; the next sync pushes it

--take-remote-all

Resolve every remaining conflict with the origin's version

Paths named by `--keep-local` keep this machine's version; every other conflict takes the origin's. Use it on a newly connected machine, where each existing file that differs is a separate conflict.

--keep-local-all

Resolve every remaining conflict by keeping this machine's version

Paths named by `--take-remote` take the origin's version; every other conflict keeps this machine's. Each kept path must already be saved.

-h, --help

Print help Arguments:

<PATH>

Not supported; a pull always applies every incoming change Examples:

Show what would be written

Resolve a conflict with the origin's version

Resolve a conflict by keeping this machine's version

Take the origin's version of every conflict except one

MISE DOTFILES RECOVER

Recover an interrupted dotfile operation

Finishes recovering from an operation that was interrupted, for example by a crash or Ctrl-C. With no argument, recovers every interrupted operation. mise restores files from the operation's recovery copies unless you have edited them since. When it cannot tell which version is safe, it lists the files: check them, then rerun with `--keep-current` to keep what is on disk and discard the operation's recovery copies. When several operations were interrupted, `--keep-current` needs the ID of one. Git history is not changed.

Usage: mise dotfiles recover [OPTIONS] [<OPERATION>]

Options:

--keep-current

Keep the files on disk instead of restoring the recovery copies

-y, --yes

Discard the operation's recovery copies without prompting

-h, --help

Print help Arguments:

<OPERATION>

The operation's checkpoint ID (see `mise dot history --pending`) or a unique prefix of its UUID Examples:

Recover every interrupted operation

Keep the files on disk for operation 42

MISE DOTFILES ROLLBACK

Return files to the version a checkpoint holds

Without `--to`, each path returns to its most recent saved version that differs from what is on disk; other checkpoints do not affect the choice. With `--to REF`, the named checkpoint is the source, and `--all` restores everything it covers. mise saves the current state in a checkpoint first, so `mise dot undo` can reverse the rollback.

Usage: mise dotfiles rollback [OPTIONS] [<PATH>] ...

Options:

--to <REF>

The checkpoint to roll back to: numeric ID, `latest`, `latest~N`, or `commit:<sha>`

--all

With `--to`, restore everything the checkpoint covers

-n, --dry-run

Show the plan without changing anything

-y, --yes

Apply without prompting

--force

Replace a path whose type changed (file, symlink, directory)

-h, --help

Print help Arguments:

<PATH>

Paths to roll back (files or directories) Examples:

Restore the latest saved version that differs from the file

Restore ~/.zshrc as checkpoint 42 holds it

Preview restoring every file from three checkpoints ago

MISE DOTFILES SAVE

Save a checkpoint of the tracked files now

Exits non-zero when history cannot save or a named path is not tracked. With no changes since the latest checkpoint, nothing is saved unless you pass `--description`, `--label`, `--task`, or a `--trigger` other than `save`.

`--best-effort` turns a failure to write the checkpoint, such as missing Git, into a warning for update scripts that run under `set -e`. A disabled history or an untracked path still fails.

A save re-encrypts the files it captures to the current `[history.encryption] recipients`. `--re-encrypt` also re-encrypts the encrypted files it does not capture: files with `autosave = false` that it does not name, and variants for other platforms. It re-encrypts their saved versions and saves no unsaved edit. Run it after changing recipients so a machine added to the list can read every file. This machine must be able to unlock each one; otherwise nothing is saved and the error lists each file it cannot unlock.

Usage: mise dotfiles save [OPTIONS] [<PATH>] ...

Options:

-d, --description <TEXT>

A description for the checkpoint

--trigger <TRIGGER>

Record the checkpoint as a save, agent, or update checkpoint

Default: save

--task <ID>

The ID of the task an agent is working on, recorded with the checkpoint

--label <LABEL>

A label to find the checkpoint by later

--best-effort

Warn instead of failing when the checkpoint cannot be written

--re-encrypt

Re-encrypt every saved encrypted file to the current recipients

-h, --help

Print help Arguments:

<PATH>

Paths to save; every one must be tracked Examples:

Save every tracked file that changed

Save one file with a description

Warn instead of failing in a script

Re-encrypt every encrypted file after changing recipients

MISE DOTFILES STATUS

Show the state of your dotfiles and their history

Lists the `[dotfiles]` entries that need attention, and counts the rest; `--verbose` lists every entry. Each has a state: `applied`, `missing`, `differs`, `source missing`, `tracked`, `would remove` for an `absent` entry whose target is still there, or `absent` for a removal that is done. A tracked entry whose variants all select other machines, such as one for an inactive profile, says `not on this machine`. Then shows the history state in sections: Tracking, Repository, Conflicts, Automatic capture, and Bootstrap, ending with the next steps.

Files a dotfile group deployed that no active entry deploys now are listed as `orphaned`: the group was deselected or removed, or a new `exclude` or a deleted source dropped them. `mise dot apply --prune` removes them.

Template entries are rendered to compare their output, so trusted template functions may run. `--json` prints `files`, `edits`, and `history`, with each entry's origin and a state of `applied`, `missing`, `differs`, `source_missing`, or `tracked`. Orphaned files appear in a separate `orphaned` array with the state `orphaned`, or `orphaned_changed` when the file was modified after it was deployed. See https://mise.jdx.dev/dotfiles/reference.html#status-states for every state.

Usage: mise dotfiles status [OPTIONS] [<TARGET>] ...

Options:

--truncate

Truncate long terminal output to fit the available width

Default: true

-J, --json

Output in JSON format

--missing

Exit with code 1 if any dotfile is not in its desired state (missing, source missing, or differs)

-v, --verbose

List every entry, including those already applied or tracked

By default the table lists only entries that need attention or have omitted files, with a one-line summary of the rest. Naming targets lists them regardless.

--prompt-secrets

Prompt for `[bootstrap.secrets]` values that templates need and the environment does not set

-h, --help

Print help Arguments:

<TARGET>

Only show these targets Examples:

Show what needs attention

List every entry

Show one target

Print the state as JSON

Exit 1 if anything is out of date, for scripts and CI

MISE DOTFILES SYNC

Push saved checkpoints and fetch incoming changes

Fetches the origin branch and pushes your local history to it. If the push is rejected, mise fetches again and reconciles the two histories without rewriting either. Incoming changes and conflicts are recorded for `mise dot pull`; this command never changes your files. With `--fetch-only`, or in `fetch-only` mode, nothing is pushed.

The watcher does this on its own in `sync` and `fetch-only` mode (the `history.sync` setting). See https://mise.jdx.dev/dotfiles/sync.html

Usage: mise dotfiles sync [OPTIONS]

Options:

--fetch-only

Fetch without pushing

--allow-plaintext-history

Allow pushing older unencrypted versions of files that are now encrypted, and versions that look like they contain secrets

--best-effort

Warn instead of failing when the origin is unreachable

-h, --help

Print help Examples:

Push and fetch now

Fetch without pushing

MISE DOTFILES TRACK

Track a file or directory in place

Adds a `[dotfiles]` entry with `mode = "track"` to your global config: the file stays where it is, nothing is copied or linked, and mise saves a checkpoint of it right away. While the watcher service runs, later edits are saved automatically; without it, `mise dot save` saves them. Use `--dry-run` to see what a large directory would add before tracking it.

`--os` and `--profile` declare a variant: machines that match the platform or config environment keep their own version of the file, so a Mac and a Linux machine can have different contents at the same path. `--machine` gives every machine its own version instead, for files such as a monitor layout that should never be applied on another machine.

See https://mise.jdx.dev/dotfiles/history.html

Usage: mise dotfiles track [OPTIONS] <PATH> ...

Options:

--os <OS>

Declare a variant for this platform (macos, linux, linux/arm64, …)

--profile <PROFILE>

Declare a variant for this config environment (`MISE_ENV` or `-E`)

--local

Keep this file's history on this machine only; it is never shared

--machine

Keep a separate stream on every machine, never applied on another

--no-autosave

Save only on `mise dot save <path>`, never automatically

--encrypt

Encrypt contents before saving them to history (requires `[history.encryption] recipients`)

--allow-plaintext

Save an explicitly tracked credential-named file in plaintext

-y, --yes

Accepted for compatibility; track no longer asks to confirm the paths

-n, --dry-run

Show what each path expands to (files, size, what is left out) without tracking it

-h, --help

Print help Arguments:

<PATH>

Paths to track (absolute or starting with ~/) Examples:

Track a file and a directory

Show what tracking a directory would save

Keep a separate version for macOS machines

Keep a separate version on every machine

Keep the file's history on this machine only

Encrypt the file before saving it

Save the file only when you run mise dot save

MISE DOTFILES UNAPPLY

Remove files that `mise dot apply` deployed

Removes the targets of whole-file entries and the blocks and lines that edit entries added, but only what mise can identify as its own. Modified copies, modified templates, and plain-line edits need `--force`. Merged keys, `absent` entries, and permissions-only targets are left alone. Sources and config entries are kept, so run this before you delete a declaration, while mise can still identify its targets.

With `--group`, removes only that dotfile group's files, using what mise recorded when it applied them, so it works even after the group is deselected or deleted from the config.

Usage: mise dotfiles unapply [OPTIONS] [<TARGET>] ...

Options:

-f, --force

Remove modified or otherwise ambiguous managed files and lines

-n, --dry-run

Print the actions that would run without writing anything

-y, --yes

Skip the confirmation prompt

--group <NAME>

Only unapply the files of this dotfile group, even one that is no longer selected or declared

--prompt-secrets

Prompt for `[bootstrap.secrets]` values that templates need and the environment does not set

-h, --help

Print help Arguments:

<TARGET>

Only unapply these targets Examples:

Remove every target mise can identify

Remove one target

Remove one dotfile group's files

Preview what would be removed

Also remove modified targets, without prompting

MISE DOTFILES UNDO

Reverse the tracked-file changes from an operation

Restores exactly the paths that an operation changed from the checkpoint it saved first, and leaves everything else as it is now. Without a reference, reverses the newest operation that has not been undone.

Works for operations that changed tracked files: `mise bootstrap`, `mise dot add`, `apply`, `edit`, `unapply`, `capture`, `rollback`, `pull` (including changes the watcher applied), and `undo` itself. Package installations, service state, and untracked files are not reversed.

Usage: mise dotfiles undo [OPTIONS] [<REF>]

Options:

-n, --dry-run

Show the plan without changing anything

-y, --yes

Apply without prompting

-h, --help

Print help Arguments:

<REF>

The operation's checkpoint: numeric ID, `latest`, `latest~N`, or `commit:<sha>` Examples:

Reverse the newest operation

Show what would be restored

Reverse the operation recorded as checkpoint 42

MISE DOTFILES UNTRACK

Stop tracking a file or directory

Removes the path's `mode = "track"` entry from your global config. When a project or system config declares the entry, mise turns it off on this machine in `config.local.toml` next to your global config instead.

A path inside a tracked directory has no entry of its own: mise adds a rule for it to `[history] exclude` in the global config, and `mise dot include <path>` removes that rule. The file itself and its existing checkpoints are not changed.

Usage: mise dotfiles untrack [OPTIONS] <PATH> ...

Options:

-h, --help

Print help Arguments:

<PATH>

Paths to stop tracking Examples:

Stop saving ~/.zshrc

Exclude one directory inside a tracked directory

MISE DOTFILES WATCH

Save tracked files as they change

Runs in the foreground and saves a checkpoint once a changed file has been quiet for `history.watch.debounce`. A file that keeps changing does not delay the others and is still saved every `history.watch.max_interval`. The watcher also rescans every tracked path at startup, every `history.watch.reconcile`, and when the configuration changes. Entries tracked with `--no-autosave` are not watched.

With an origin connected, the watcher also syncs according to the `history.sync` setting. In `sync` mode it pushes within `history.sync_interval` of a save, fetches every `history.fetch_interval`, and applies incoming changes when there are no conflicts. In `fetch-only` mode it only fetches; in `manual` mode it does not use the network. A failed sync is retried with backoff while saving continues. `--once` runs one rescan and one sync, then exits.

The built-in `history-watch` service runs this for you:

[bootstrap.services.mise-history]
builtin = "history-watch"

Exits 0 when history is disabled or another watcher is already running, and 1 when Git is unusable, the store cannot be opened, or no watch can be installed. A failed save is retried with backoff and never drops the pending changes, and a save that would overlap another history operation is deferred. With `--once`, nothing is retried: a save that fails or is deferred, or a sync that fails, exits 1.

Usage: mise dotfiles watch [OPTIONS]

Options:

--once

Rescan and sync once, then exit (for timers and cron)

-J, --json

Print one JSON object per line instead of log lines

-h, --help

Print help Examples:

Watch and save until stopped

Rescan and sync once, for a timer

Print JSON lines instead of log lines

MISE DOCTOR

Check your mise setup for problems

Prints mise's version, whether shell activation and shims are set up, its directories, the config files, tools, and environment in use, and its settings, then lists any problems and warnings with a suggested fix. Exits with status 1 when it finds a problem. Include this output when you report a bug.

Usage: mise doctor [OPTIONS] [COMMAND]

Options:

-J, --json

Output in JSON format

-h, --help

Print help Examples:

Check the setup and list problems

Print the report as JSON

MISE DOCTOR PATH

Print the directories mise adds to PATH

Lists tool bin directories and `_.path` entries from [env]. --full prints the whole PATH mise would set. `mise bin-paths` lists tool bin directories only.

Usage: mise doctor path [OPTIONS]

Options:

-f, --full

Print every PATH entry, including those mise does not provide

-h, --help

Print help Examples:

Print the directories mise adds to PATH

Print the whole PATH mise would set

MISE DOCTOR PROJECT

Run the project's diagnostic checks

Checks are declared in `[doctor.checks.<name>]` tables in mise.toml. Each command runs with the project's installed tools and environment. Checks should inspect state; mise does not sandbox them or run their suggested remedies. Exits with status 1 when a check fails. See https://mise.jdx.dev/configuration/project-diagnostics.html.

Usage: mise doctor project [OPTIONS]

Options:

-J, --json

Output the complete report as JSON

-h, --help

Print help Examples:

Run every check and report pass or fail

Print the report as JSON

MISE EN

Start a subshell with mise's tools and environment

This is an alternative to `mise activate` for starting a mise session explicitly. The new shell has the tools and environment variables from the config loaded. Unlike an activated shell, changing directories does not update the environment. Type `exit` to leave it.

Usage: mise en [OPTIONS] [<DIR>]

Options:

-s, --shell <SHELL>

Shell to start; defaults to $SHELL

-h, --help

Print help Arguments:

<DIR>

Directory to start the shell in

Default: .

Examples:

Start a shell with the project's tools and environment

Start the shell in another project

Skip loading .bashrc

Skip loading .zshrc

MISE ENV

Print the environment for the current configuration

Evaluate the shell output to load tools and variables once, without installing prompt hooks. Changing directories afterward does not recompute this environment. Use `mise exec -- command` to apply it to one child process instead.

JSON, dotenv, and shell output contain actual variable values, including secrets. `--redacted` selects variables marked for redaction; it does not mask their values. Tools you pass as TOOL@VERSION arguments are installed first if they are missing; missing tools from the config are reported, not installed.

Usage: mise env [OPTIONS] [<TOOL@VERSION>] ...

Options:

-D, --dotenv

Output in dotenv format

-J, --json

Output in JSON format

-s, --shell <SHELL>

Shell type to generate environment variables for

--json-extended

Output in JSON format with additional information (source, tool)

--redacted

Only include variables marked for redaction; their values are printed unmasked

--values

Only show values of environment variables

--paths

Print the PATH entries mise manages, in PATH order, one per line

-h, --help

Print help Arguments:

<TOOL@VERSION>

Tools to include in addition to those in the config, such as `node@24` Examples:

Load the environment once into the current bash session

Same, for zsh

Same, for fish

Same, for xonsh

Print the variables as JSON

List the PATH entries mise manages, such as tool bin directories

Write a dotenv file; it contains secret values

MISE EXEC

Run a command with mise's tools and environment

Loads the tools and [env] from your config into one child process without changing the current shell. Use it in scripts and CI, or to run a tool that is not in the config.

TOOL@VERSION arguments add tools or override the configured version of that tool only: with `node = "24"` in mise.toml, `mise exec [email protected] -- python -V` still has node 24 on PATH.

Put the command after `--`, or pass a shell command string with `-c`. Missing tools are installed first unless the `exec_auto_install` or `auto_install` setting is off; when you name tools, only those are installed. The --allow-* and --deny-* flags sandbox the command; see https://mise.jdx.dev/sandboxing.html.

Usage: mise exec [OPTIONS] [<TOOL@VERSION>] ... [<COMMAND>] ...

Options:

-c, --command <COMMAND>

Command string to run through a shell (supports pipes and redirection)

-j, --jobs <JOBS>

How many tools to install in parallel; defaults to the `jobs` setting

Values below 1 are treated as 1.

Environment: MISE_JOBS

--allow-env <VAR>

Pass only VAR through from the environment (implies --deny-env)

Supports wildcards, such as --allow-env='MYAPP_*'.

--allow-net <HOST>

Allow network access only to HOST (not supported on any platform)

Per-host filtering does not work: Linux and macOS exit with an error, and Windows runs the command without network restrictions. See https://mise.jdx.dev/sandboxing.html#access-to-particular-hosts

--allow-read <PATH>

Allow reads from PATH (implies --deny-read for everything else)

--allow-write <PATH>

Allow writes to PATH (implies --deny-write for everything else)

--deny-all

Block reads, writes, network, and env vars

--deny-env

Block env var inheritance except PATH, HOME, USER, SHELL, TERM, COLORTERM, LANG

On Windows it also keeps the variables programs need to start, such as SystemRoot and TEMP.

--deny-net

Block all network access

--deny-read

Block filesystem reads (system libs and tool dirs still accessible)

--deny-write

Block filesystem writes except temporary and device paths (/tmp, /dev)

--fresh-env

Bypass the environment cache and recompute the environment

--no-deps

Skip automatic dependency preparation

--raw

Connect install commands directly to the terminal; implies --jobs=1

--secrets <SECRET>

[experimental] Give the command these secrets (comma-separated); by default it gets none

--secrets-all

[experimental] Give the command every secret the project can inject, except file secrets

-h, --help

Print help Arguments:

<TOOL@VERSION>

Tools to add or override, such as `node@24 [email protected]`

<COMMAND>

Executable and arguments to run directly, after `--` Examples:

Run app.js with node 24

Run a shell command string

Run in another project's directory

Run without network access

[experimental] Pass one secret from the project's secrets source

MISE FMT

Format mise TOML configuration

Formats the config files in the current directory in place; --all formats every config file mise loads. Use --check in CI to fail when a file is not formatted, or --stdin to format a document from stdin to stdout.

Formatting normalizes whitespace and writes TOML 1.1 syntax, including multiline inline tables. Top-level entries written as plain, dotted, or inline-table keys go in a standard order: min_version, env_file, env_path, _, env, vars, hooks, watch_files, tools, other keys, tasks, task_config, redactions, alias, plugins, settings. `[table]` sections and the keys inside any table keep the order they were written in.

Lists whose order has no effect are sorted: task `sources` and `outputs`, `task_config.global_inputs` and `input_groups`, and `redactions`. File pattern lists put `@group:` references first, then globs, then literal paths. A list with a `!` exclusion or a comment is left as written.

Usage: mise fmt [OPTIONS]

Options:

-a, --all

Format every config file mise loads, not only those in the current directory

-c, --check

Check whether the configs are formatted without rewriting them; exits 1 if any are not

-s, --stdin

Format TOML from stdin and print it to stdout, without touching any file

-h, --help

Print help Examples:

Format the config files in the current directory

Exit 1 if any config file needs formatting

Print a formatted copy without changing the file

MISE GENERATE

Generate project files such as CI workflows, git hooks, and scripts

Usage: mise generate [OPTIONS] <COMMAND>

Options:

-h, --help

Print help

MISE GENERATE CONFIG

Generate a mise.toml file

Same as `mise edit`, which has the details. It opens the interactive editor, or without an interactive terminal (or with --yes) writes a commented starter template. If PATH already exists it stops with an error rather than replace the file; pass --force to replace it.

Usage: mise generate config [OPTIONS] [<PATH>]

Options:

-g, --global

Generate the global config file (~/.config/mise/config.toml)

-n, --dry-run

Print the result instead of writing it to the file

-f, --force

Replace an existing file with the starter template when not opening the editor

-t, --tool-versions <FILE>

Copy the tools from this .tool-versions file into the config, without opening the editor

-h, --help

Print help Arguments:

<PATH>

Config file to edit or create; defaults to mise.toml Examples:

Edit mise.toml in the current directory

Print the result instead of writing it

MISE GENERATE DEVCONTAINER

Generate a devcontainer configuration that installs mise and the project's tools

Prints JSON by default. `--write` saves .devcontainer/devcontainer.json in the repository root (or the current directory outside a git repository), replacing an existing file. Review the image, mounts, and setup commands before opening it.

Usage: mise generate devcontainer [OPTIONS]

Options:

-i, --image <IMAGE>

Base image; defaults to mcr.microsoft.com/devcontainers/base:ubuntu

-m, --mount-mise-data

Keep installed tools in a `mise-data-volume` Docker volume so they survive rebuilds

Mounts the volume at /mnt/mise-data, sets MISE_DATA_DIR to it, and adds its shims directory to PATH.

-n, --name <NAME>

Container name; defaults to mise

-w, --write

Write to .devcontainer/devcontainer.json instead of printing

-h, --help

Print help Examples:

Print the configuration

Keep installed tools in a volume and save .devcontainer/devcontainer.json

MISE GENERATE GIT-PRE-COMMIT

Generate a git hook that runs a mise task

The hook runs `mise run <TASK>` (default `pre-commit`) with the staged file names in the STAGED environment variable. It prints the hook unless you pass --write, which saves it in the repository's hooks directory and makes it executable.

For hooks that git gives a message file (commit-msg, prepare-commit-msg, applypatch-msg, sendemail-validate), the task gets that file as an argument. Other hook arguments, such as a pre-push hook's remote name and URL, are not passed on.

For a full git hook manager, see hk: https://hk.jdx.dev

Usage: mise generate git-pre-commit [OPTIONS] [<MISE_ARG>] ...

Options:

-t, --task <TASK>

The task to run when the hook is triggered

Default: pre-commit

-w, --write

Write the hook to the hooks directory and make it executable

The hooks directory is `.git/hooks`, or `core.hooksPath` when it is set. An existing hook of the same name is moved to `<HOOK>.old`.

--hook <HOOK>

Which git hook to write, such as pre-push

Default: pre-commit

-h, --help

Print help Arguments:

<MISE_ARG>

mise flags to embed in the generated hook, given after `--`

These are inserted between `mise` and `run`, so the hook carries the same context you would pass on the command line. Useful when the config is not at the repository root, since git runs hooks from the top level: `-- -C subdir` makes the hook find it. Examples:

Install the hook; each commit then runs `mise run pre-commit`

Use the config in subdir, since git runs hooks from the repository root

MISE GENERATE GITHUB-ACTION

Generate a GitHub Actions workflow that runs a mise task

The workflow runs the task named by --task on pull requests, tags, manual dispatch, and pushes to the current branch. It prints YAML unless you pass --write, which saves `.github/workflows/<NAME>.yml` in the repository root and replaces an existing file. Define the task and review the triggers before committing the workflow.

Usage: mise generate github-action [OPTIONS]

Options:

-t, --task <TASK>

The task to run when the workflow is triggered

Default: ci

-w, --write

Write the workflow to `.github/workflows/<NAME>.yml` instead of printing it

--name <NAME>

Name of the workflow and its file

Default: ci

-h, --help

Print help Examples:

Print a workflow that runs the ci task

Save it as .github/workflows/ci.yml

Save a workflow that runs the lint task as .github/workflows/lint.yml

MISE GENERATE INSTALL-SCRIPT

Generate a script that downloads and runs a pinned mise

Commit the script, for example as bin/mise, so contributors and CI can run `./bin/mise install` without installing mise first. On first run it downloads the pinned mise version into the mise data directory, or into the project with --localize, then runs it with the arguments it was given.

`mise generate bootstrap` is a deprecated alias for this command and will be removed in mise 2027.9.0.

Usage: mise generate install-script [OPTIONS]

Options:

-l, --localize

Keep mise data and cache in a project-local directory (`.mise` by default)

Use `--localized-dir` to choose its location. This isolates mise state; it is not an OS sandbox for commands the generated script runs.

-V, --version <VERSION>

mise version to pin; defaults to the release `mise self-update` would install

-w, --write <PATH>

Write the script to PATH (./bin/mise when no path is given) and make it executable, instead of printing it

--localized-dir <DIR>

Directory for mise data when using --localize, relative to the project

Default: .mise

--windows

Also write a Windows launcher, `<PATH>.cmd`

Windows cannot run the bash script. Generate the launcher on any OS and commit it for contributors on Windows. Requires --write.

-h, --help

Print help Examples:

Write ./bin/mise; on first run it downloads the pinned mise, then runs it

Keep mise and its tools in .mise inside the project

Also write bin/mise.cmd for contributors on Windows

MISE GENERATE TASK-DOCS

Generate Markdown documentation for project tasks

Documents the tasks defined for the current directory. Prints to stdout by default. Use `--output` to write a file, `--inject` to replace a marked section, or `--multi` for one file per task.

Usage: mise generate task-docs [OPTIONS]

Options:

-i, --inject

Replace the marked section of the --output file

Replaces everything between `<!-- mise-tasks -->` and `<!-- /mise-tasks -->` in the --output file, so you can rerun it to update the docs. The file must already contain both markers; mise reports an error and leaves the file unchanged if either is missing.

-I, --index

Write only an index of tasks, intended for use with `--multi`

-m, --multi

Render each task as a separate document; requires `--output` to be a directory

-o, --output <PATH>

Write the generated docs to a file or directory

-r, --root <ROOT>

Has no effect; tasks always come from the current directory

-s, --style <STYLE>

Has no effect; both styles produce the same output

Default: simple

-h, --help

Print help Examples:

Print the task documentation

Write the task documentation to TASKS.md

Update the marked section of README.md

MISE GENERATE TASK-STUBS

Generate scripts that run mise tasks

Writes one executable stub per task into a directory, such as `bin/test` for the `test` task, that runs the task with mise. Pair them with `mise generate install-script` so contributors can run tasks without installing mise. When a task has subtasks, the parent's stub is written to `<parent>/_default`.

Hidden tasks and global tasks are skipped: the stubs are committed to the project, and global tasks come from each user's own config.

Usage: mise generate task-stubs [OPTIONS]

Options:

-d, --dir <DIR>

Directory to create task stubs inside of

Default: bin

-m, --mise-bin <PATH>

mise executable the stubs run; defaults to mise from PATH

Use `--mise-bin ./bin/mise` with a script from `mise generate install-script`. On Windows a path runs as written, so that script needs its `.cmd` launcher beside it; generate it with `mise generate install-script --write ./bin/mise --windows`. The default, `mise`, is a bare name that resolves from PATH and needs nothing extra.

Default: mise

--windows-launcher <KIND>

What to write beside each stub for Windows to launch

`cmd` writes `<task>.cmd`. cmd.exe re-parses the whole line before `%*` expands, so an argument containing `& ^ | " %VAR%` does not reach the task intact when the launcher is called from PowerShell.

`exe` writes a native `<task>.exe` instead, which receives its arguments unchanged from every shell. It is a copy of the mise-shim.exe that ships with the Windows build, so it can only be generated on Windows, and it adds ~220KB per task to a directory that is normally committed.

Default: cmd

-h, --help

Print help Examples:

Write a stub for each task into ./bin

Make the stubs run the mise that `mise generate install-script` wrote

MISE GENERATE TOOL-STUB

Generate or update a tool stub

A tool stub is an executable file that names a tool and where to get it; running it installs the tool if needed and runs it. See https://mise.jdx.dev/dev-tools/tool-stubs.html.

Pass --url or --platform-url to create or extend a stub. mise downloads each artifact to record its checksum, size, and binary path unless you pass --skip-download. On an existing stub, new platforms are added and URLs you pass again are replaced. --fetch fills in missing checksums and sizes, and --lock records lock data for an existing stub, including one that uses a registry tool.

Usage: mise generate tool-stub [OPTIONS] <OUTPUT>

Options:

-b, --bin <BIN>

Binary path within the extracted archive

If not specified and the archive is downloaded, mise detects the most likely binary.

--bootstrap

Make the stub install mise when it is missing

The stub becomes a bash script that: 1. Uses mise from PATH, or ~/.local/bin/mise 2. Otherwise installs mise to ~/.local/bin with the embedded installer 3. Runs the tool stub with mise

--bootstrap-version <BOOTSTRAP_VERSION>

mise version the --bootstrap script installs; defaults to the latest release

Pin a version such as `2026.10.0` to keep the installer reproducible.

--checksum-algorithm <ALGORITHM>

Checksum algorithm for downloaded artifacts

Not available with --lock or --skip-download, which do not compute checksums.

Default: blake3

--fetch

Fetch checksums and sizes for an existing tool stub file

Reads an existing stub file and fills in missing checksum and size fields by downloading the files. URLs must already be present in the stub.

--http <HTTP>

Has no effect; kept so existing scripts that pass it keep working

Default: http

--lock

Resolve and record lock data (exact version, platform URLs and checksums) for an existing stub

The data goes into the `mise.lock` of the nearest project config above the stub, and the stub keeps its version request. It is an error when no project config is found.

--platform-bin <PLATFORM_BIN>

Binary path inside the archive for one platform, such as `linux-x64:bin/tool`; repeatable

--platform-url <PLATFORM_URL>

Download URL for one platform, as `PLATFORM:URL` or a bare URL; repeatable

With a bare URL, mise detects the platform from the file name, such as `--platform-url https://nodejs.org/dist/v24.11.0/node-v24.11.0-darwin-arm64.tar.gz`. When the output file already exists, new platforms are added to its platforms table, and a platform you pass again gets the new URL.

--skip-download

Do not download artifacts, so checksums, sizes, and the detected binary path are left out

-u, --url <URL>

URL to download the tool from

--version <VERSION>

Version of the tool

Default: latest

-h, --help

Print help Arguments:

<OUTPUT>

Output file path for the tool stub Examples:

Download and inspect a real archive to detect its binary and checksum

Add a Linux artifact to the same stub

Draft a stub without downloading; replace the placeholder URL before running it

Fill missing checksums and sizes in an existing stub

Resolve and record the version and platform lock data of an existing registry-backed stub

MISE IMPLODE

Remove the mise CLI and all related data

Deletes the mise executable and the data (including installed tools), state, and cache directories. It also deletes the system-wide shared directory used by `mise install --system` (MISE_SYSTEM_DATA_DIR, default /usr/local/share/mise), which other users on the machine may rely on. It asks before each removal; --yes skips the prompts. The config directory stays unless you pass --config.

If a package manager such as Homebrew or apt installed mise, uninstall it with that package manager instead. Remove the `mise activate` line from your shell startup file yourself. See https://mise.jdx.dev/installing-mise.html#uninstalling.

Usage: mise implode [OPTIONS]

Options:

-n, --dry-run

Print what would be removed, without removing anything

--config

Also remove the config directory

-h, --help

Print help Examples:

List what would be removed

MISE EDIT

Edit mise.toml interactively

Opens a terminal editor for PATH (default: mise.toml in the current directory) where you can add tools from the registry, pick versions, and set environment variables, tasks, and settings. It pre-fills tools it detects from files in the current directory, such as `.node-version`.

Without an interactive terminal, or with --yes, it writes a commented starter template instead. If PATH already exists it stops with an error rather than replace the file; pass --force to replace it. Use --dry-run to print the result without writing it.

Usage: mise edit [OPTIONS] [<PATH>]

Options:

-g, --global

Edit the global config file (~/.config/mise/config.toml)

-n, --dry-run

Print the result instead of writing it to the file

-f, --force

Replace an existing file with the starter template when not opening the editor

-t, --tool-versions <FILE>

Copy the tools from this .tool-versions file into the config, without opening the editor

-h, --help

Print help Arguments:

<PATH>

Config file to edit or create; defaults to mise.toml Examples:

Edit mise.toml in the current directory

Edit another config file

Edit the global config

Copy the tools from .tool-versions into mise.toml

Print the result instead of writing it

Write a commented starter config to a new file without opening the editor

Replace an existing mise.toml with the starter config

MISE INSTALL

Install the tools in your config, or specific tool versions

With no arguments, installs every tool version your config requests that is not installed yet. With TOOL@VERSION arguments, installs those versions; a bare tool name installs the version your config requests for it.

Installing does not add a tool to your config, so a tool you have not configured is not on PATH. Use `mise use` to install a tool and add it to mise.toml, or `mise exec <TOOL>@<VERSION> -- <COMMAND>` to run it once.

Versions install in parallel (see --jobs) under the mise data directory, by default `~/.local/share/mise/installs/<TOOL>/<VERSION>`.

Usage: mise install [OPTIONS] [<TOOL@VERSION>] ...

Options:

-f, --force

Reinstall even if already installed

With no TOOL arguments, reinstalls every configured tool.

-j, --jobs <JOBS>

How many tools to install in parallel; defaults to the `jobs` setting

Values below 1 are treated as 1.

Environment: MISE_JOBS

-n, --dry-run

Show what would be installed, without installing anything

-v, --verbose

Show installer output

Prints each backend's download, configure, and compile output.

--dry-run-code

Like --dry-run, but exit with status 1 when anything needs installing

Use it in scripts to check whether `mise install` has work to do.

--include-task-tools

Also install tools required by tasks in the current scope

This prepares task tools without running task commands or dependencies. Combine with --monorepo to include tasks from every configured root.

--include-lazy

Also install tools configured with `lazy = true`

By default, a bare `mise install` leaves lazy tools to be installed the first time you run one of their commands.

--minimum-release-age <AGE>

Only install versions released before a date or at least a duration ago

Takes a date such as `2024-06-01` or a duration such as `90d` or `1y`. Overrides the `minimum_release_age` setting and tool option.

--monorepo

Also install tools from every config root in `[monorepo].config_roots`

Requires `monorepo_root = true` and an explicit `config_roots` list in the monorepo root's config. Uses the active MISE_ENV.

Environment: MISE_MONOREPO

--raw

Connect install commands directly to the terminal; implies --jobs=1

--shared <DIR>

Install into DIR instead of the mise data directory

May require elevated permissions, depending on the path.

--system

Install into the system-wide shared directory

Installs to /usr/local/share/mise/installs (or MISE_SYSTEM_DATA_DIR/installs). On Unix, binary-download backends invoke sudo to publish into protected system directories unless system_packages.sudo is disabled. Run mise as your user, without sudo.

-h, --help

Print help Arguments:

<TOOL@VERSION>

Tools to install, such as `node@24`; defaults to every tool in the config Examples:

Install every tool the config requests

Install the node version the config requests

Install the latest node 24.x release

Install an exact version

Also install tools marked lazy = true

Also install the tools your tasks need

MISE INSTALL-INTO

Install a tool version into a directory outside mise

Downloads or builds TOOL@VERSION into PATH for use without mise. mise does not track the result, so it does not appear in `mise ls`.

If PATH is not empty, mise asks before deleting its contents; --yes deletes them without asking.

Usage: mise install-into [OPTIONS] <TOOL@VERSION> <PATH>

Options:

-h, --help

Print help Arguments:

<TOOL@VERSION>

Tool and version to install, such as `node@24`

<PATH>

Directory to install into; its existing contents are deleted Examples:

Install node 24 into ./mynode and run it

MISE INSTALLS

[experimental] Inspect and choose identity-layout installations

With `install_layout = "identity"`, each installation lives in its own `<label>-<hash>` directory, and several installations of one version can exist side by side (different options, platforms, pinned artifacts, or a refreshed copy). These commands list them, choose which one mise uses when no lockfile pins one, and move installations made before you turned the layout on into it. With no subcommand, runs `mise installs ls`. See https://mise.jdx.dev/dev-tools/install-layout.html.

Usage: mise installs [OPTIONS] [COMMAND]

Options:

-h, --help

Print help

MISE INSTALLS LS

List the installations of the identity install layout

Every installation is listed separately, so variants of one version (made with different options, or pinned to different artifacts by lockfiles) can be told apart. The Status column marks the installation mise uses when no lockfile pins one (`selected`), installations a lockfile pins (`pinned`), and installations in a read-only shared installs directory (`shared`).

Usage: mise installs ls [OPTIONS] [<TOOL>] ...

Options:

-J, --json

Output in JSON format

--no-header

Do not print the table header

-h, --help

Print help Arguments:

<TOOL>

Only show the installations of these tools Examples:

List every installation in the identity layout

List the installations of node as JSON

MISE INSTALLS MIGRATE

Reinstall legacy installations into the identity install layout

Installations made before `install_layout = "identity"` was turned on stay in `installs/<tool>/<version>` and keep working; mise never moves them on its own, because tools record their own path in shebangs, virtual environments and package-manager files. This reinstalls each one into its own `<label>-<hash>` directory, then removes the old directory and puts the version link in its place, so a path that pointed into the old directory still resolves.

Each version is reinstalled from its backend, not copied, so the files are written for their new path. Run it while nothing is using the tools: the old directory is moved aside while its replacement installs, and put back if that fails. Versions whose recorded backend is not the one their tool resolves to now are left alone, as are tools that keep the legacy layout (`http:`, `rust`, `dotnet`).

A version that cannot be reinstalled (its release was withdrawn or is signed by someone else now, or the network is unavailable) is not an error: its directory is moved as it is into the identity layout, behind the same version link. Only a version that cannot be moved either keeps its old directory, reported as kept in the legacy layout. The command ends with a count of what was migrated, relocated, kept and failed, and fails only when a migration itself broke.

Usage: mise installs migrate [OPTIONS] [<TOOL@VERSION>] ...

Options:

-n, --dry-run

Show what would move without changing anything

-h, --help

Print help Arguments:

<TOOL@VERSION>

Only migrate these tools, or these versions of them

Defaults to every legacy installation. Examples:

List the legacy installations that would move

Move every installed node and one python version

MISE INSTALLS SELECT

Choose which installation mise uses when no lockfile pins one

Several installations can match the same request, such as a refreshed copy next to one a lockfile pinned, or installations made for different lockfiles. For a request with no lockfile entry, mise uses the installation selected for that tool, version, platform, and options. If none is selected and several match, mise stops and tells you to run this command.

The selection is shared by every project on this machine that makes the same request without a lockfile. Projects whose lockfile pins an artifact keep the installation of that artifact. The version link (`installs/<tool>/<version>`) is pointed at the selected installation.

Usage: mise installs select [OPTIONS] <INSTALLATION>

Options:

-h, --help

Print help Arguments:

<INSTALLATION>

The installation to select: its directory name, or its path Examples:

Find jq's installations

Use this one for requests with no lockfile entry

MISE LATEST

Print the latest version that matches a version request

`mise latest node` prints the latest release, and `mise latest node@22` the latest 22.x release. Each backend decides what "latest" means, for example whether prereleases count and how channels and refs resolve. Nothing is installed and no config changes.

Usage: mise latest [OPTIONS] <TOOL@VERSION> [<ASDF_VERSION>]

Options:

-i, --installed

Print the latest installed version instead of the latest available one

--minimum-release-age <AGE>

Only consider versions released before a date or at least a duration ago

Takes a date such as `2024-06-01` or a duration such as `90d` or `1y`. Overrides the `minimum_release_age` setting and tool option.

-h, --help

Print help Arguments:

<TOOL@VERSION>

Tool, optionally with a version prefix, such as `node` or `node@22`

<ASDF_VERSION>

The version prefix to use when querying the latest version same as the first argument after the "@" used for asdf compatibility Examples:

Print the latest node release

Print the latest node 22.x release

Print the latest installed node 22.x version

Skip releases from the last 30 days

MISE LINK

Symlink a tool version into mise

Use this to register an install that was compiled by hand or built with another tool. mise uses the version exactly as written, such as `[email protected]` or a name of your own like `node@brew`; `latest`, aliases, and channels are rejected.

Usage: mise link [OPTIONS] <TOOL@VERSION> <PATH>

Options:

-f, --force

Replace an existing installation of this version

-h, --help

Print help Arguments:

<TOOL@VERSION>

Tool and version to create a symlink for

<PATH>

Directory of the existing installation, such as `~/.nvm/versions/node/v24.11.0` Examples:

Link a node that node-build built into ~/.nodes/24.11.0

Register Homebrew's node as node@brew; then run `mise use node@brew`

MISE LOCK

Create or refresh lockfile versions, checksums, and download URLs

Operates on the current config root, including tools declared by tasks. Existing matching locked versions are preserved unless `--bump` re-resolves their requests. This command does not install tools; `--dry-run` previews changes.

`mise lock TOOL@VERSION` locks that exact version. When the version falls outside the configured request, such as `[email protected]` with `tiny = "2"`, mise also updates the request in mise.toml to match.

Usage: mise lock [OPTIONS] [<TOOL>] ...

Options:

-g, --global

Lock only the global and system config lockfiles

These are ~/.config/mise/mise.lock and the system config's lockfile. By default, only the current project's config root is locked.

-j, --jobs <JOBS>

How many jobs to run in parallel; defaults to the `jobs` setting

Values below 1 are treated as 1.

Environment: MISE_JOBS

-n, --dry-run

Show what would change, without writing anything

-p, --platform <PLATFORM>

Platforms to lock, comma-separated, such as `linux-x64,macos-arm64`

Defaults to the `lockfile_platforms` setting plus the current platform when that setting is configured, else the platforms already in the lockfile, else a common set for a new lockfile.

--bump

Re-resolve version requests against the latest available versions

By default, `mise lock` refreshes metadata for the currently locked versions. With this flag, requests such as "latest", "lts", or prefixes such as "24" are re-resolved against the latest matching remote versions, so the lockfile advances without installing anything. `--bump` never modifies config files: exact versions resolve to themselves and stay unchanged (use `mise upgrade --bump` to rewrite pins in mise.toml). If the remote versions cannot be fetched, it fails rather than keep the locked version.

--json

Output version changes as JSON

Prints an array of objects describing lockfile version changes: name, backend, lockfile, old_versions, new_versions. Version lists keep config/lockfile order; they are not sorted. Only version-level changes are reported: checksum and URL refreshes for unchanged versions produce no entries, so `mise lock --json` prints `[]` when no version changed, even though it still updates the lockfile. Suppresses the human-readable output. Combine with `--dry-run` to detect available updates without writing the lockfile.

--local

Update mise.local.lock, for tools in mise.local.toml, instead of mise.lock

--minimum-release-age <AGE>

Only lock versions released before a date or at least a duration ago

Takes a date such as `2024-06-01` or a duration such as `90d` or `1y`. Overrides the `minimum_release_age` setting and tool option. It filters only requests that are not exact, such as "24" or "latest"; exact versions such as "24.11.0" are not filtered. Existing matching lockfile entries are kept; this flag alone does not downgrade them.

--upgrade

Upgrade lockfiles to the latest format

mise keeps an existing lockfile at its format version during normal updates, so collaborators on an older mise can still read it. This flag rewrites it in the newest format, which adds request bindings, dependency-graph sidecars, and packslip repository IDs. It processes every configured tool and cannot be combined with tool arguments. See https://mise.jdx.dev/dev-tools/mise-lock-reference.html#format-versions.

--sidecars

List native dependency sidecars instead of updating lockfiles

Backends such as npm and pypi keep a tool's locked dependency graph in a sidecar directory next to mise.lock; see https://mise.jdx.dev/dev-tools/mise-lock-reference.html#native-dependency-sidecars. For each existing lockfile in scope, prints the sidecar directory mise keeps its dependency graphs in and every sidecar directory the lockfile references. Nothing is resolved, installed, or written. Paths are relative to the current directory when they are inside it, and absolute otherwise, such as the sidecars of a symlinked lockfile. Combine with `--json` for machine-readable output, or with `--local` and `--global` to choose the lockfiles.

-h, --help

Print help Arguments:

<TOOL>

Tools to lock, such as `node python`; defaults to every configured tool and every tool a task needs

Use `tool@version` to lock an exact version. If it falls outside the configured request, mise.toml is updated to match. Examples:

Create or refresh the project lockfile

Refresh only node and python

Lock an exact version; mise.toml keeps a request such as "24"

Lock only the linux-x64 platform

Show what would change

Re-resolve requests such as "latest" or "24" to the latest matching versions

List available updates as JSON without writing

Lock versions released before 2024-01-01 for requests that are not exact

Update mise.local.lock

Update only the global lockfiles

MISE LS

List installed and active tool versions

Lists the tools mise knows about: versions that are installed, and versions requested by a config file (active) whether or not they are installed. Each row shows the tool, the version (marked `(missing)` when it is not installed, or `(lazy)` when it is a lazy tool that installs on first use), the config file that requests it, and the request as written.

Usage: mise ls [OPTIONS] [<INSTALLED_TOOL>] ...

Options:

--truncate

Truncate long terminal output to fit the available width

Default: true

-b, --backend <BACKEND>

Only show tools from this backend, such as aqua, cargo, core, or go

Registry shorthands count as the backend they resolve to, so `jq` is listed under aqua. Repeat the flag to show several backends.

-c, --current

Only show versions the loaded config files request

-g, --global

Only show versions the global config requests

-i, --installed

Only show installed versions

Hides requested versions that are not installed.

--grouped

List tools in a separate section for each backend

Cannot be combined with --json; use --backend to filter JSON output.

-J, --json

Output in JSON format

-l, --local

Deprecated alias for --no-global

Removed in mise 2027.7.0.

--no-global

Only show versions that non-global config files request

Includes config files in parent directories and skips the global config, system config, and `MISE_<TOOL>_VERSION` environment variables. See --project for the nearest project's config alone.

--project

Only show versions the nearest project config requests

The project is the nearest directory, starting at the current one and moving up, that has a mise config file. Every config file in that directory counts, such as `mise.toml`, `mise.local.toml`, `conf.d` fragments, `.tool-versions` and idiomatic version files. Configs in parent directories and global or system configs do not, nor do `MISE_<TOOL>_VERSION` environment variables. A version that a later file in that directory overrides is not listed, as with --no-global; `mise uninstall --project` still removes it.

-m, --missing

Only show requested versions that are not installed

-o, --offline

Don't fetch information such as outdated versions

-p, --plugin <PLUGIN>

--all-sources

Show requests from every config file mise has seen, not only loaded ones

mise tracks the config files it loads so `mise prune` keeps the versions they use.

--monorepo

Also list tools from every config root in `[monorepo].config_roots`

Requires `monorepo_root = true` and an explicit `config_roots` list in the monorepo root's config. Uses the active MISE_ENV.

Environment: MISE_MONOREPO

--no-header

Do not print the header row

--outdated

Show whether each version is outdated

--prefix <PREFIX>

Only show versions starting with PREFIX (requires a tool argument)

--prunable

List only tools that can be pruned with `mise prune`

-h, --help

Print help Arguments:

<INSTALLED_TOOL>

Only show these tools Examples:

Show installed versions and the requests from the loaded config files

Show only versions the loaded config files request

Find requested versions that are not installed

Machine-readable output: an object keyed by tool name

With a tool argument, JSON output is an array of its version records

Include requests from every config file mise has seen

Show only tools from the go or cargo backends

List tools in a separate section for each backend

MISE LS-REMOTE

List tool versions available to install

Results may be cached; run `mise cache clear TOOL` to refresh one tool before querying it again. Version formats and ordering are backend-specific.

Usage: mise ls-remote [OPTIONS] [<TOOL@VERSION>] [<PREFIX>]

Options:

--all

List available versions for every tool mise currently knows about

--minimum-release-age <AGE>

Only show versions released before a date or at least a duration ago

Takes a date such as `2024-06-01` or a duration such as `90d` or `1y`. Overrides the `minimum_release_age` setting and tool option.

-J, --json

Output in JSON format, with metadata such as `created_at` when available

--no-versions-host

Fetch versions from the tool's upstream instead of mise's version mirror

Same as `use_versions_host = false` for this command.

--prerelease

Include prerelease versions

Works for backends that report prerelease metadata or detect prereleases by pattern. Same as MISE_PRERELEASES=1 or the `prereleases` setting, for this command only.

--strict-metadata

Exit with an error when release metadata cannot be fetched

Without it, backends such as aqua and ruby fall back to a version list without release dates, or an empty one. Requires --json and --no-versions-host.

-h, --help

Print help Arguments:

<TOOL@VERSION>

Tool to get versions for

<PREFIX>

Version prefix to filter by; same as `TOOL@PREFIX` Examples:

List every node version

List node 24.x versions

Skip versions released in the last 30 days

Include release dates, as JSON

MISE LSP

Run the language server for mise config files over stdin/stdout

Editors start this command and exchange Language Server Protocol messages with it.

It serves `mise.toml` and the other config files mise loads (`.mise.toml`, `mise.<env>.toml`, `mise.local.toml`, `mise/config.toml`, and the files of a `conf.d`). It ignores every other file, including files that `[task_config] includes` lists, so it can be attached to the TOML language without touching `Cargo.toml` or `pyproject.toml`.

It offers: - diagnostics: TOML syntax errors, unknown keys with a suggestion, values of the wrong type, deprecated keys, task names no task defines (`unknown-task`), and dependency cycles (`task-cycle`) - completion of keys, including inside inline tables, and of values that have a fixed set - hover documentation for keys - for tools: completion of tool names under `[tools]` from the registry, and hover with the tool's description and backends - quick fixes that replace an unknown key or task name with the suggested one, and rewrite a deprecated key to its replacement when the schema names one - formatting, as `mise fmt` does - semantic tokens, which color task, tool and env var names, env directives, deprecated keys and the `{{ }}` and `{% %}` of templates - for tasks: completion of task names in `depends`, `depends_post`, `wait_for` and `run = [{ task = "..." }]` (and of templates in `extends`), hover with the task's description and command, go to definition, find references, and rename together with every reference in the file

Tasks come from the open file, the configs in the directories above it and the TOML files their `[task_config] includes` name.

A client that runs another TOML server beside this one can switch features off with `initializationOptions`: `{"formatting": false, "hover": false, "completion": false, "definition": false, "references": false, "rename": false, "semanticTokens": false}`.

The server only parses a config. It never renders templates or runs anything, so opening an untrusted file is safe.

A mise that predates this command runs a task named `lsp` instead, so a client that needs to know whether the command exists can check that `mise help lsp` prints `Usage: mise lsp`.

See https://mise.jdx.dev/ide-integration.html for editor configuration.

Usage: mise lsp [OPTIONS]

Options:

-h, --help

Print help Examples:

Start the server; an editor's LSP configuration runs this command

MISE MCP

Run the Model Context Protocol server over stdin/stdout

Exposes project tools, tasks, environment, and configuration to an MCP client. The client, such as an AI coding assistant, starts this command and exchanges messages with it. Start it in the project directory or pass `--cd`: the resources describe that project.

Resources (JSON): - mise://tools: active tool versions (?include_inactive=true adds the rest) - mise://tasks: task definitions, including monorepo subproject tasks - mise://env: environment variables - mise://config: loaded config files and the project root

Environment resources contain real values, including secrets.

Tools: - list_commands: every mise command and its declared effect - run_task: run a task with your permissions; it can change files and call
external services - install_tool: install a tool version, as `mise install` does

run_task and install_tool refuse a project whose config files are not trusted; run `mise trust` there after reviewing them.

See https://mise.jdx.dev/mcp.html for client configuration and access controls.

Usage: mise mcp [OPTIONS]

Options:

-h, --help

Print help Examples:

Serve a project from another directory, as an MCP client config does

MISE OCI

[experimental] Build, push, and run OCI images of a project's tools

Each tool version becomes its own image layer, so changing one tool version rebuilds that tool's layer instead of the whole image.

Requires `mise settings experimental=true` (or `MISE_EXPERIMENTAL=1`). Behavior, flags, and output layout may change in future releases. See https://mise.jdx.dev/dev-tools/mise-oci.html

Usage: mise oci [OPTIONS] <COMMAND>

Options:

-h, --help

Print help

MISE OCI BUILD

[experimental] Build an OCI image from the current mise.toml

Each tool version becomes its own content-addressable OCI layer. Bumping a tool version invalidates that tool's layer (a Python bump also invalidates pypi tool layers, which are relocated against it); other tool layers and the base image layers are reused, while the generated /etc/mise/config.toml layer, image config, and manifest are regenerated. The output directory follows the OCI image-layout spec.

Only tools from project config files are packaged, including a monorepo root's config. The global and system configs and a config directly in your home directory, such as ~/mise.toml, are left out unless you pass `--include-global`.

Build on a Linux host with the image's architecture. Tools are packaged as installed on the host, and so is the running mise binary, at /usr/local/bin/mise, unless you pass `--no-mise`. asdf plugins are not supported; use a vfox plugin or any other backend for each tool. vfox plugins are copied into the image next to the tools they install.

Requires `mise settings experimental=true` (or `MISE_EXPERIMENTAL=1`).

Usage: mise oci build [OPTIONS]

Options:

--copy <HOST_PATH:IMAGE_PATH>

Copy a host file, directory, or symlink into the image (repeatable, HOST:IMAGE)

-o, --output <OUTPUT>

Output directory for the OCI image layout

Default: ./mise-oci

--from <FROM>

Base image reference (overrides [oci].from and the oci.default_from setting)

--include-global

Also package tools from the global and system configs

By default `mise oci build` packages only project config files, including a monorepo root's config. With this flag it also includes the tools, `[oci]`, `[bootstrap.packages]`, and `[dotfiles]` of the global and system configs and of a config directly in your home directory, so personal tools from ~/.config/mise/config.toml end up in the image.

-t, --tag <TAG>

Tag to record in the image index (the org.opencontainers.image.ref.name annotation)

--mount-point <MOUNT_POINT>

Where tools install inside the image

Overrides [oci].mount_point and the oci.default_mount_point setting.

--no-mise

Do not embed the currently-running mise binary at /usr/local/bin/mise

--no-cache

Rebuild tool layers without reading or writing the local layer cache

--owner <UID[:GID]>

UID[:GID] to assign to every tar entry in generated layers

Overrides [oci].user_id and [oci].group_id. Defaults to 0:0. If GID is omitted, it defaults to UID. This affects file ownership only; [oci].user controls the image USER directive.

-h, --help

Print help Examples:

Build the project's image into ./mise-oci

Use another base image and record a tag

Inspect the result

Open a shell in it

MISE OCI PUSH

[experimental] Build an OCI image and push it to a registry

Builds from the project's config, as `mise oci build` does, unless `--image-dir` names an image layout built earlier. Then uploads only the blobs the registry does not already have. mise pushes with its own registry client, so skopeo, crane, and docker are not needed.

Tool layers whose tool, version, mount point, and file owner match the previously pushed image (or `--cache-from`) are reused without being rebuilt, so those tools need not be installed locally. Pass `--no-cache` to rebuild every tool layer.

Credentials come from the files docker and podman use: `$REGISTRY_AUTH_FILE`, `$XDG_RUNTIME_DIR/containers/auth.json`, `~/.config/containers/auth.json`, then `~/.docker/config.json`, including inline auths and credential helpers. Log in with `docker login` or `podman login`.

Requires `mise settings experimental=true` (or `MISE_EXPERIMENTAL=1`).

Usage: mise oci push [OPTIONS] <REF>

Options:

--cache-from <REF>

Reuse unchanged tool layers from this image instead of the destination's current tag

Must be in the same repository as the destination. Useful when every push gets a new tag, as with per-commit tags in CI: `mise oci push --cache-from ghcr.io/me/dev:latest ghcr.io/me/dev:$SHA`. Cannot be combined with --no-cache.

--from <FROM>

Base image for the build

Overrides [oci].from and the oci.default_from setting.

--image-dir <IMAGE_DIR>

Push an existing OCI image layout instead of building one

Cannot be combined with --cache-from, --from, --include-global, --mount-point, --no-mise, or --owner.

--include-global

Also package tools from the global and system configs

See `mise oci build --help` for details.

--mount-point <MOUNT_POINT>

Where tools install inside the image

Overrides [oci].mount_point and the oci.default_mount_point setting.

--no-cache

Rebuild tool layers without using the remote or local layer cache

--no-mise

Do not embed the running mise binary at /usr/local/bin/mise

--owner <UID[:GID]>

UID[:GID] to assign to every tar entry when building

Overrides [oci].user_id and [oci].group_id. Defaults to 0:0. If GID is omitted, it defaults to UID. This affects file ownership only; [oci].user controls the image USER directive.

--update-index

Maintain the tag as a multi-arch image index

Pushes this build's manifest by digest and points the tag at an OCI image index containing one entry per platform, preserving entries other architectures pushed. Run `mise oci push --update-index` from one runner per platform to assemble a multi-arch tag.

-h, --help

Print help Arguments:

<REF>

Destination registry reference (e.g. `ghcr.io/me/devenv:latest`) Examples:

Build and push to GHCR

Push an image built earlier

MISE OCI RUN

[experimental] Build the project's image and run a command in it

Builds the image as `mise oci build` does, unless `--image-dir` names an existing layout, then loads it into podman or docker and runs the command in a container with stdin, stdout, and stderr attached. podman reads the OCI layout directly; docker receives it through `docker load`.

Requires `mise settings experimental=true` (or `MISE_EXPERIMENTAL=1`) and podman or docker.

Usage: mise oci run [OPTIONS] [<CMD>] ...

Options:

--engine <ENGINE>

Container engine to use; `auto` prefers podman and falls back to docker

Default: auto

--from <FROM>

Base image for the build

Overrides [oci].from and the oci.default_from setting.

--image-dir <IMAGE_DIR>

Use an existing OCI image layout instead of building one

Cannot be combined with --from, --include-global, --mount-point, --no-mise, or --owner.

--include-global

Also package tools from the global and system configs

See `mise oci build --help` for details.