[Bug] `install.sh` doesn't source uv's env after installing it: first-time users get "uv not found" or "kimi: command not found"

Summary

The bash installer at scripts/install.sh (served as https://code.kimi.com/install.sh) has a structural bug that hits first-time users on systems where ~/.local/bin is not already on the bash subshell's PATH. The Windows installer (scripts/install.ps1) handles this correctly; the bash one does not.

What the upstream uv installer does

https://astral.sh/uv/install.sh (which install.sh pipes into sh) installs the uv binary to ${XDG_BIN_HOME:-$HOME/.local/bin} and writes an env script at ${XDG_BIN_HOME:-$HOME/.local/bin}/env. It modifies shell rc files (~/.profile, ~/.bashrc, ~/.zshenv, etc.) for future shells. It does not export PATH in the current shell session — that is exactly why it ends with the message:

To add $HOME/.local/bin to your PATH, either restart your shell or run:
source $HOME/.local/bin/env (sh, bash, zsh)

The bug

After install_uv returns, scripts/install.sh immediately runs:

if ! command -v "$UV_BIN" >/dev/null 2>&1; then
  echo "Error: uv not found after installation." >&2
  exit 1
fi

"$UV_BIN" tool install --python 3.13 kimi-cli

Two failure modes follow from this:

1. Hard failure (script aborts). On a system where ~/.local/bin is not on the bash subshell's PATH (fresh container images, freshly created user accounts, some minimal distros), the upstream installer drops uv into ~/.local/bin but does not put that directory on PATH. command -v "$UV_BIN" returns non-zero, and the script exits with Error: uv not found after installation.
2. Soft failure (script "succeeds" but kimi is unreachable). When ~/.local/bin is already on the subshell's PATH, command -v uv finds it and uv tool install runs. But uv installs kimi into the user's tool-bin directory (typically also ~/.local/bin). If the user's interactive shell startup files don't yet have that directory on PATH (e.g. ~/.local/bin was just created by this run), the next kimi --version returns command not found. The user has no obvious link back to the installer for what went wrong.

Compare to install.ps1

scripts/install.ps1 explicitly refreshes the session PATH from machine + user environment after installing uv:

$env:PATH = "$($MachinePath.TrimEnd(';'));$($UserPath.TrimEnd(';'))"...

That is the equivalent of sourcing the env file. The bash installer should do the same.

Proposed fix

Source the env file uv writes (it handles both PATH and any future env additions), with a small fallback for older uv versions that may not write one:

install_uv() {
  if command -v curl >/dev/null 2>&1; then
    curl -fsSL https://astral.sh/uv/install.sh | sh
  elif command -v wget >/dev/null 2>&1; then
    wget -qO- https://astral.sh/uv/install.sh | sh
  else
    echo "Error: curl or wget is required to install uv." >&2
    exit 1
  fi

  # The upstream uv installer writes ${XDG_BIN_HOME:-$HOME/.local/bin}/env
  # and prints "Run 'source ...' to add uv to your PATH" — but does not
  # source it. Source it ourselves so the rest of THIS script can find uv.
  local uv_env="${XDG_BIN_HOME:-$HOME/.local/bin}/env"
  if [ -f "$uv_env" ]; then
    # shellcheck disable=SC1090
    . "$uv_env"
  else
    # Fallback for very old uv installers without an env script.
    export PATH="${XDG_BIN_HOME:-$HOME/.local/bin}:$PATH"
  fi
}

Two follow-ups worth considering at the same time:

• Print a clear "shell setup" line at the very end of install.sh:

  Installed kimi to ~/.local/bin/kimi.
  Restart your shell, or run:    source ~/.local/bin/env
  to start using `kimi`.
  

• Add a CI smoke test: run install.sh inside debian:stable-slim and alpine, then assert kimi --version works in the same shell. That'd catch this class of bug forever.

Why this matters

This is the very first command a new user runs. If it produces "kimi: command not found" — or worse, exits with Error: uv not found after installation. — the user concludes the tool is broken before they have ever tried it.

Note on verification

I verified this from code reading + the upstream installer's documented behavior (the source at https://releases.astral.sh/installers/uv/latest/uv-installer.sh shows it writing to $INFERRED_HOME/.local/bin/env and editing ~/.profile, not the running shell). I have not executed install.sh end-to-end myself, but the logic is structurally identical to the same bug pattern fixed in install.ps1. If the maintainers want a CI repro, the smoke test above will reproduce it deterministically in debian:stable-slim.

Start with scripts/install.sh and compare its post-install PATH handling with scripts/install.ps1. Check the uv installation and the subsequent uv and kimi lookups, then verify that a fresh shell environment can run kimi --version after the script completes. Done means the installer can find uv and makes kimi available in the same session or clearly reports the required shell setup.