Forward config environments (MISE_ENV) to mise bootstrap remote

[rotsix]

Summary

mise bootstrap remote runs mise bootstrap inside the staged project on the target, but no config environment reaches that process, so mise.<env>.toml files cannot take part in a remote bootstrap.
I would like a way to declare, per inventory host, which config environments the remote run should load.

Current behaviour

mise 2026.8.8. src/system/remote.rs, run_staged:

let mut argv = vec![
    "env".to_string(),
    format!("MISE_TRUSTED_CONFIG_PATHS={project}"),
    mise,
    "--cd".to_string(),
    project,
    "bootstrap".to_string(),
];

followed by conditional pushes for --dry-run, --yes, --update, --prompt-secrets, --force-dotfiles, --skip and --only.

The resulting remote command, captured by putting a logging ssh on PATH:

env 'MISE_TRUSTED_CONFIG_PATHS=/tmp/mise-bootstrap.XXXX/project' \
  /usr/local/bin/mise --cd /tmp/mise-bootstrap.XXXX/project bootstrap --dry-run --yes

Running the orchestrator as mise -E linux bootstrap remote <host> produces exactly the same remote command.
Neither RemoteRunOptions nor RemoteHostTomlConfig carries an environment field, so this reads as a gap rather than a decision.

Setting [env] MISE_ENV = "..." in the staged mise.toml does not help either, since environment selection happens during config discovery, before [env] is evaluated.

Why platform detection does not cover this

mise bootstrap already gates by OS, and that part works well.
On macOS a config carrying [bootstrap.users] logs ignoring [bootstrap.users] and [bootstrap.groups] on non-Linux host and applies the [bootstrap.macos.*] sections instead.

Two things platform gating cannot express:

1. [dotfiles] is not platform gated, and a workstation and a server usually want different sets.
2. Roles are not a platform property at all. server vs workstation vs ci is precisely what config environments are for, and it is the axis a fleet tends to be organised along.

Use case

A dotfiles repo with mise.macos.toml, mise.linux.toml, mise.server.toml and mise.dotfiles.toml.
Locally I run mise -E macos,dotfiles bootstrap.
For a server I would like the remote to run with server,linux,dotfiles, chosen by me, per host, in versioned config.

Proposal

A per-host inventory key, emitted into the env prefix that already exists:

[bootstrap.remote.hosts.nas]
host = "nas"
mise_env = ["server", "linux", "dotfiles"]

producing:

env 'MISE_TRUSTED_CONFIG_PATHS=...' 'MISE_ENV=server,linux,dotfiles' mise --cd ... bootstrap --yes

Per-host rather than inherited from the orchestrator, because the local environment is rarely meaningful on the target: a laptop running -E macos should not push macos to a Linux box.
A [bootstrap.remote].mise_env default and a --remote-env CLI override would compose the same way the existing source and exclude keys already do.

Workarounds today

Relative remote_mise resolves inside the staged project, so a committed shim works:

remote_mise = "./mise-server"

#!/bin/sh
PATH="$HOME/.local/bin:$PATH"
command -v mise >/dev/null 2>&1 || curl -fsSL https://mise.run | sh
exec mise -E server,linux,dotfiles "$@"

This works but bypasses bootstrap_command, because provision_mise returns early when remote_mise is set, so the shim has to install mise itself.

ssh_options = ["SendEnv=MISE_ENV"] is also passed through correctly, but it needs AcceptEnv MISE_ENV in the target's sshd_config, which is circular when the point is to bootstrap that host in the first place.

Note on the docs

The remote page states that local environment variables are deliberately not copied to SSH hosts.
I read that as being about secret transport, since it sits in the --prompt-secrets paragraph.
If it is also meant to rule out config environment selection, that would be worth saying explicitly, because the two seem like different concerns.

Happy to open a PR if the per-host key is the shape you would want.

[jdx]

Thanks for the detailed report—the diagnosis and proposed configuration shape were right. I opened #12182 to implement it.

The PR adds:

• [bootstrap.remote].mise_env as the inventory default
• per-host mise_env as a replacement override
• --remote-env as the command-line override
• explicit MISE_ENV injection into the staged bootstrap command

The resulting precedence is --remote-env > host mise_env > remote default > unset. The orchestrator’s -E remains local and is not implicitly forwarded.

AI-assisted — Tool: Codex; model: unavailable/unavailable; version: unavailable.

[rotsix]

I took 2 hours away from keyboard, I come back with both an answer and a merged PR ready for release. You're awesome, thanks again for Mise!