From mise-toolkit
When to use `mise activate` vs `mise activate --shims` vs `mise exec` vs `mise env` vs `mise en` vs `mise run` — what each does, what each loads, and what each can't. Use when the user is choosing between activation methods, or when something works in one mode but not another (especially "[env] vars not set in IDE").
npx claudepluginhub ray-manaloto/claude-code-marketplace --plugin mise-toolkitThis skill uses the workspace's default tool permissions.
mise has six ways to put tools on PATH and load env vars. They're NOT interchangeable. Each has trade-offs.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Checks Next.js compilation errors using a running Turbopack dev server after code edits. Fixes actionable issues before reporting complete. Replaces `next build`.
Guides code writing, review, and refactoring with Karpathy-inspired rules to avoid overcomplication, ensure simplicity, surgical changes, and verifiable success criteria.
Share bugs, ideas, or general feedback.
mise has six ways to put tools on PATH and load env vars. They're NOT interchangeable. Each has trade-offs.
| Method | How it works | Loads [env]? | Loads hooks? | watch_files? | Best for |
|---|---|---|---|---|---|
mise activate | Shell prompt hook (hook-env) | ✅ | ✅ | ✅ | Interactive shells |
mise activate --shims | Adds ~/.local/share/mise/shims to PATH once | ❌ | ❌ | ❌ | IDEs, scripts, login shells |
mise exec / mise x | Sets env, runs one command, exits | ✅ | ❌ | ❌ | One-off commands, scripts, CI |
mise env | Prints env vars to eval | ✅ | ❌ | ❌ | Integration with other tools |
mise en | Starts a sub-shell with env loaded | ✅ | ❌ | ❌ | Quick "throw me into a project shell" |
mise run | Sets env, runs a task, exits | ✅ | ❌ | ❌ | Task execution from anywhere |
mise activateThe full version. Hooks into your shell prompt, runs mise hook-env on every prompt display, updates PATH and env vars when you change directories or edit mise.toml.
eval "$(mise activate zsh)" # in your ~/.zshrc
Pros:
enter/leave/cd/postinstall), watch_files.cd in, everything updates.Cons:
mise activate --shimsLighter mode. Adds the shims directory to PATH and stops. Each shim is a wrapper script that re-invokes mise to figure out the right tool version.
eval "$(mise activate zsh --shims)"
Pros:
Cons:
[env] variables. This is the #1 confusion.enter/leave/etc.).When to use: IDEs that don't have a mise plugin. Scripts called from cron. Login shells where you want tools available without the prompt hook.
mise exec / mise xmise x -- node script.js
mise exec node@22 -- node -v
Reads the config, sets up env + PATH, runs the command, exits. No hooks. No watch_files. But [env] IS loaded.
Pros:
[env] (unlike shims).mise x node@22 -- node -v.Cons:
When to use: scripts, CI, one-off commands without changing your shell.
mise enveval "$(mise env)" # bash/zsh
mise env --shell fish | source
Prints export commands for the current mise.toml. You eval them yourself.
Pros: integration with non-shell consumers (e.g., mise env --json for tools that read JSON).
Cons: doesn't update on directory change. Manual.
When to use: integration glue. Sometimes useful for one-off "set up a shell with this project's env".
mise enmise en # starts a sub-shell with env loaded
mise en /path/to/project # for a specific project
Spawns a new shell with mise env active.
Pros: quick exploration without modifying your rc.
Cons: nested shell — exiting drops you back to the original.
When to use: "let me poke around in this project for a minute".
mise runmise run test
mise run build && mise run test
Loads env + tools, runs a defined task (from [tasks] or mise-tasks/), exits.
Pros: the canonical way to run project tasks. Handles task deps, parallelism, sources/outputs caching.
Cons: only runs defined tasks, not arbitrary commands.
When to use: anything you've defined as a task. Compose with depends/depends_post.
--shims and [env]If a user reports "my [env] vars aren't set", the first thing to check is whether they're using --shims mode. Shims mode does not load [env]. To get env vars, they need:
mise activate (no --shims), ORmise exec / mise x to wrap the command, ORmise run for tasksThe shims-only IDE pattern is fine for tool versions but won't load [env]. If your tools need env vars, use a mise IDE plugin (which talks to mise directly) or wrap your run/debug command in mise x.
Most teams want both: full activation interactively, shims for IDEs.
# ~/.zprofile (login → IDEs read this)
eval "$(mise activate zsh --shims)"
# ~/.zshrc (interactive)
eval "$(mise activate zsh)"
Now:
[env]..zshrc AND .zprofile, getting full activation.If you have multiple PATH manipulators in your rc (mise, nvm, pyenv, direnv, brew shellenv), order matters. The LAST one wins for PATH.
Recommended order:
# 1. brew shellenv (if you use brew)
eval "$(/opt/homebrew/bin/brew shellenv)"
# 2. anything else that touches PATH
# 3. mise activate LAST so it wins
eval "$(mise activate zsh)"
If mise loses to nvm, you'll see ~/.nvm/versions/node/... instead of ~/.local/share/mise/installs/node/... in which node.
| Method | Overhead |
|---|---|
mise activate | ~5ms per prompt (hook-env exits early if nothing changed) |
mise activate --shims | ~10ms per tool invocation |
mise exec | ~30-50ms per call (loads config + sets up env) |
mise run | Same as exec, plus task overhead |
For comparison, asdf shims add ~120ms per tool invocation. mise's shims are an order of magnitude faster.
mise-shell-activation — the actual snippets per shell/mise-activate-shell commandmise-overview — the FAQ table this skill expands on