Coding agents

A coding agent such as Claude Code or Codex runs each command in a non-interactive shell. mise activate in your .zshrc or .bashrc never runs there, so the agent does not get the project's tools or [env] unless it wraps the command in mise x -- or the shell finds shims on PATH.

Both work, but they have costs. Wrapping every command is noisy and agents forget to do it. Shims resolve a tool from the directory the command runs in, so a tool that the current directory's config does not select fails with No version is set for shim.

mise has no agent-specific mode. The pieces it already has are enough: mise hook-env is what mise activate runs before each prompt, and it works without a prompt. Running it before each command gives the agent the same PATH and variables that an activated interactive shell has.

Claude Code {#claude-code}

Claude Code sources the file named by $CLAUDE_ENV_FILE before each Bash command it runs. Only SessionStart, Setup, CwdChanged and FileChanged hooks can write to it. Add this to ~/.claude/settings.json, or to a project's .claude/settings.json:

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "[ -n \"$CLAUDE_ENV_FILE\" ] && echo 'eval \"$(mise hook-env -s bash)\"' >> \"$CLAUDE_ENV_FILE\"; true"
          }
        ]
      }
    ]
  }
}

The hook appends one line:

eval "$(mise hook-env -s bash)"

Use -s zsh if Claude Code runs commands in zsh. The line runs before every command, so it follows the directory the agent is in when a command starts: after the agent runs cd subproject, its next command gets that project's tools, and leaving removes them. It does not refresh in the middle of one command, so in cd subproject && node --version the node is still the parent project's. When nothing changed since the last command, hook-env prints nothing and costs a few milliseconds.

The line must be able to find mise. The installer can leave ~/.local/bin off the PATH of a shell that does not run mise activate, which includes the agent's. If command -v mise fails there, write the absolute path into the hook instead, for example eval "$(~/.local/bin/mise hook-env -s bash)".

If you prefer a fixed environment for the whole session, write the output of mise env once instead. It is evaluated at session start, in the directory the session started in, and does not follow cd:

mise env -s bash >> "$CLAUDE_ENV_FILE"

Either way, the agent can then run node, cargo or python directly, and the project's [env] variables are set.

mise does not install missing tools on its own here. Run mise install in the project first, or have the agent do so. A config that mise does not trust is not loaded.

Codex {#codex}

Codex runs commands through your login shell by default, so the tools in your login profile apply. Add shims to your login profile and run mise install in the project. Shims are weaker than the Claude Code setup: they put a project's [env] variables only on the tool they launch and its children, so echo "$FOO" in the shell still sees nothing, and a tool the current directory's config does not select fails with No version is set for shim. Check Codex's own documentation for how it selects the shell, because mise cannot change that. This setup has not been tested here the way the Claude Code hook has.

Other agents

Any agent that sources a file before each command, or lets you point its shell at an rc file, can use the same line. A command that only runs once at session start is not enough on its own, because it changes just that process and its children, and later commands do not inherit it. That is why the Claude Code hook writes to a file instead of running hook-env itself. If the agent offers neither, the fallback is shims on PATH in the login profile, with the limits described above.

Worktrees {#worktrees}

Agents often work in a git worktree, such as .claude/worktrees/<name>. The hook-env line needs nothing per worktree, because it reads the config of whichever directory the command runs in. Shims are the likelier trap here: a worktree is often where No version is set for shim appears, since the shim resolves tools from the worktree's own config.

Installed tools live in mise's data directory, not in the worktree, so a new worktree does not reinstall them.

Related

• AI assistants (MCP) lets an assistant read a project's tasks and config and run tasks through mise mcp.
• Shims explains the trade-offs between shims and PATH activation.