BerriAI/litellm · error · UpError

Could not find `lite` on your PATH. Claude Code's apiKeyHelp

Error message

Could not find `lite` on your PATH. Claude Code's apiKeyHelper needs an absolute path to it, so `lite up` cannot continue.

What it means

Raised by `lite up` (UpError from resolve_api_key_helper in litellm/proxy/client/cli/commands/up.py) when shutil.which("lite") returns None. Before patching ~/.claude/settings.json, `up` must embed an absolute path to the `lite` executable into Claude Code's apiKeyHelper command, because the subprocess Claude Code later spawns may see a different PATH. If the current process cannot resolve `lite`, the helper command cannot be built and `up` aborts before touching any files.

Source

Thrown at litellm/proxy/client/cli/commands/up.py:152

        resolved_settings_path.unlink()
    resolved_backup_path.unlink()
    return record


def resolve_api_key_helper(base_url: str) -> str:
    """Build the shell command Claude Code should run for its apiKeyHelper.

    Resolves `lite` to an absolute path so the helper works regardless of the
    PATH visible to whatever subprocess Claude Code spawns it from. Passing
    --base-url explicitly (rather than relying on the bare invocation Claude
    Code would otherwise use) makes `print-token` enforce that the cached
    token was actually issued for this proxy -- without it, a token minted
    for a different, previously-logged-into proxy would be handed to
    whichever server `up` currently points at.
    """
    lite_path: Final = shutil.which("lite")
    if lite_path is None:
        raise UpError(
            "Could not find `lite` on your PATH. Claude Code's apiKeyHelper needs "
            "an absolute path to it, so `lite up` cannot continue."
        )
    return f"{shlex.quote(lite_path)} auth print-token --base-url {shlex.quote(base_url)}"


def _ensure_fresh_login(ctx: click.Context) -> None:
    base_url: Final = ctx.obj["base_url"].rstrip("/")
    token_data = load_token()
    if token_data and token_data.get("base_url") == base_url and is_cli_token_fresh(token_data):
        return

    if not sys.stdin.isatty():
        raise UpError(
            "No fresh LiteLLM login found for this proxy. Run `lite login` first (apiKeyHelper "
            "reads this token on every Claude Code request)."
        )

View on GitHub (pinned to 77b7c6c40c)

Solutions

  1. Activate the environment that owns the entrypoint (e.g. `source .venv/bin/activate`) or install it isolated: `pipx install litellm && pipx ensurepath`
  2. Reload the shell (`exec $SHELL` or open a new terminal) and verify with `which lite` and `lite --version` before retrying `lite up`
  3. In CI/cron with a stripped PATH, export the bin directory explicitly first: `export PATH="$PATH:/path/to/venv/bin"`
  4. If it still fails, find where the entrypoint landed (`python -m pip show -f litellm | grep bin` or `pipx list`) and add that directory to PATH

Example fix

# before
lite up   # UpError: Could not find `lite` on your PATH ...

# after
source ~/.venvs/litellm/bin/activate   # or: pipx ensurepath && exec $SHELL
which lite   # -> /home/me/.venvs/litellm/bin/lite
lite up
Defensive patterns

Strategy: validation

Validate before calling

import shutil, subprocess, sys

lite = shutil.which("lite")
if lite is None:
    sys.exit("`lite` not on PATH — activate its venv or run `pipx ensurepath`, then retry")
raise SystemExit(subprocess.call([lite, "up"]))

Try / catch

import click
try:
    run_lite_up()  # anything that shells out to `lite up`
except click.ClickException as e:  # `up` wraps UpError in ClickException for CLI output
    exit_on_unrecoverable(e.format_message())

Prevention

When it happens

Trigger: Running `lite up` from a shell whose PATH lacks the directory holding the litellm CLI entrypoint: an unactivated virtualenv, a pipx install without `pipx ensurepath`, a non-login CI shell with a minimal PATH, or a wrapper/IDE terminal that sanitizes or drops the user's PATH entries.

Common situations: Installed litellm via pip/pipx into a user site or venv and opened a new terminal before PATH reload; running `lite up` from cron, systemd, or CI where PATH is /usr/bin:/bin; SSH session that didn't source the shell rc; installing into a different Python environment than the one whose bin dir is on PATH.

Related errors


AI-assisted analysis of BerriAI/litellm@77b7c6c40c (2026-08-18). Data as JSON: /api/errors/173befab95869507. Report an issue: GitHub.