Shell latency using mise on network drive (NFS)

[zaucker]

When using mise on a shared development server inside a NFS4 mounted Home directory, we noticed "latency" running commands or just pressing Ctrl-C in the shell the first time we entered the directory or after some idleness in that shell. Commands executed directly afterwards (with little wait in between) did not show that latency.
Moving $HOME/.cache, $HOME/.config, and $HOME/.local to a fast local SSD storage didn't help.

strace -f mise hook-env -s bash |& grep -P '^statx(' | wc

showed 108 filesystem accesses by mise, most of them to the NFS mounted storage.

We suspect that during the first run of mise, this takes a few seconds, afterwards filesystem buffering makes this fast, until the buffers "loose" this information through other filesystem usages and then the next call is slow again. There seems not much that can be done to help that with a network drive as we have no means to force filesystem buffering to be kept (which probably wouldn't play very well with the system as a whole).

For our situation, where we only rely on mise "providing" the proper tool versions without doing any env variable setting, we used this workaround:

   lazy_mise () {
     if [ x$LAST_PWD != x$(pwd) ]; then
        _mise_hook
        LAST_PWD=$(pwd)
     fi
   }
   PROMPT_COMMAND="lazy_mise;${PROMPT_COMMAND}"

in our $HOME/.bashrc files. This makes mise only do its thing when changing directories.

NOTE: this also "looses" the automatic/immediate mise run when, e.g., editing the .tool-versions file.

Just wanted to share this in case anybody else has a similar setup and annoying latency.

[iamkroot]

Relevant parts of the docs-

After activating, every time your prompt displays it will call mise hook-env to fetch new environment variables. This should be very fast. It exits early if the directory wasn't changed or mise.toml/.tool-versions files haven't been modified.

(from https://mise.jdx.dev/dev-tools/ and https://mise.jdx.dev/faq.html#what-does-mise-activate-do)

Looks like hook-env is definitely the main culprit. I have also noticed that the time taken to call mise (any subcommand, but the exact mise binary) also scales with the number of tools installed. Ah never mind, that was likely caused by a previous mise activate. Getting fast mise executions in a fresh shell session.

This becomes extremely noticeable in my case since it looks like my NFS client isn't caching anything. So every prompt has a ~5sec delay after running mise activate.

[lelandbatey]

I came to the same conclusion and recorded my thoughts in a different thread, with some fun evidence in the form of strace showing that mise will run stat on ~50 potential files per ancestor directory of the directory you're in; so the "deeper" into a file tree on an NFS drive you are, the slower mise will make things. I did build a workaround in the form of a bit of code you can put in your shell rc file after mise is sourced, a bit of code which will prevent mise from running when you're in directories of your choice. Copy-pasting, the code for that workaround is here:

## Paste this somewhere after the line in your .bashrc where mise gets set up, looks like this:
# eval "$($HOME/.local/bin/mise bash)"

# We want to add a little indirection where we can put our own logic to prevent running mise on slow
# network filesystems. When we 'cd' into a directory in Bash, how is mise hook-env getting run? The
# callgraph looks like this:
#
#     $PROMPT_COMMAND -> _mise_hook -> eval "$(mise hook-env -s bash)"
#
# Thus, it seems like the thing to do is to try to re-define the `_mise_hook` function so that it
# won't run in blocklisted paths.

# In order to change the _mise_hook implementation so that it won't run `mise hook-env -s bash` if
# our current directory is in one of the blocklisted folders, we unset it then define it anew.
# Original source for _mise_hook is:
# https://github.com/jdx/mise/blob/e4888902195528bcb65767841f8b9f3daa8195f3/src/shell/bash.rs#L58
unset _mise_hook

DONT_RUN_MISE_PATHS=(
  "/run/user"
  "/mount/"
)

_should_run_mise() {
  local curdir="$1"
  for exempt_path in "${DONT_RUN_MISE_PATHS[@]}"; do
    # Normalize paths by removing trailing slashes
    exempt_path="${exempt_path%/}"
    if [[ "$curdir" == "$exempt_path" || "$curdir" == "$exempt_path"/* ]]; then
        return 1
    fi
  done
  return 0
}

_mise_hook() {
  local previous_exit_status=$?;

  if _should_run_mise "$PWD" ; then
    eval "$(mise hook-env -s bash)";
  fi
  return $previous_exit_status;
}

Putting that in my bashrc after the line sourcing mise has fixed the issue for my use case.

[Marukome0743]

A first-class version of this NFS workaround is now available.

PR #7312, included in mise v2025.12.8, added two settings intended for slow filesystems such as NFS:

[settings.hook_env]
cache_ttl = "5s"
chpwd_only = true

• hook_env.cache_ttl avoids repeating the full filesystem check until the configured duration expires.
• hook_env.chpwd_only performs the full check when the working directory changes instead of on every prompt.

They can also be configured without reading them from a config file:

export MISE_HOOK_ENV_CACHE_TTL=5s
export MISE_HOOK_ENV_CHPWD_ONLY=1

The trade-off is that a config file modified in place may not be detected immediately. A full refresh can be requested explicitly with:

mise hook-env --force

There has also been a later improvement in #10707, included in mise v2026.7.0, which reduced normal config-candidate discovery from repeated glob/stat work to a single existence check per candidate.

As a local regression check on the current main branch, I tested from a directory roughly 150 levels deep. The debug build spent about 7.7 ms in config_paths, with the complete hook-env call taking about 0.12 seconds. This is not an NFS benchmark, but it confirms that the previously expensive local config discovery path has been substantially reduced.

For an NFS setup, I would start with chpwd_only = true; add a small cache_ttl if directory changes are still expensive.

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