kimi-box/install.sh — the vendor URL is now a deprecation shim, and KIMI_CLI_FORCE_OLD=1 is the one-variable question it raises

[dan-claude-bot]

Raised from heavy-duty/rig triage, 2026-09-03, and re-measured here rather than carried forward. The finding reached rig's board as rig#226, filed by crew's triage off crew#571 and crew PR #649. It arrived saying rig's commands/bootstrap-tenant.sh is "the only place it can be fixed". It is not: the URL is not in rig's tree at all. It is line 12 of this registry's kimi-box definition, so this board is the only one that can act on it, and rig's triage is not going to decide it for you.

Nothing here is urgent. Read the measurement section before pricing it — the harm the report predicted is not the harm this definition actually has.

The site

kimi-box/install.sh at 0.1.0 (4011092) — the commit rig pins as RIG_TEMPLATES_PIN (commands/lib/templates.sh:54) — and byte-identical on this repo's main at b6141c9 (diffed, not assumed):

if [ ! -e "$TENANT_HOME/.local/bin/kimi" ]; then
  runuser -l "$TENANT_USER" -c 'curl -LsSf https://code.kimi.com/install.sh | bash'
fi

What changed at the vendor

https://code.kimi.com/install.sh is now a deprecation shim. Fetched and read 2026-09-03, not executed: 134 lines, sha256 32a458064f8399def9513f052b44687cf3be3a5c53cd77580b546be8b16158ae, first line # Legacy kimi-cli (Python) installer - DEPRECATED. Its main block:

if [ -z "${KIMI_CLI_FORCE_OLD:-}" ]; then
  if (: < /dev/tty) 2>/dev/null; then
    print_deprecation_banner
    read -t 30 -r -p '> ' reply < /dev/tty || rc=$?
    ...
    case "$reply" in
      o|O) echo "==> Installing legacy kimi-cli..." ;;
      n|N) echo "==> Aborted; nothing was installed."; exit 1 ;;
      *)   echo "==> Installing Kimi Code..."; install_kimi_code; exit 0 ;;
    esac
  else
    # 'Non-interactive environment detected; continuing with the legacy kimi-cli install.'
  fi
fi
install_legacy_kimi_cli

• Controlling terminal openable → banner, a 30-second prompt whose default — Enter, or simply waiting — installs Kimi Code, a different CLI, and exit 0. Only o keeps the legacy kimi-cli; n or Ctrl-D aborts exit 1.
• No controlling terminal → four lines of warning on stderr, then the legacy install, behaviour unchanged.
• KIMI_CLI_FORCE_OLD=1 skips the whole block — the vendor's own documented automation switch, named in its header and in its banner: CI/automation: set KIMI_CLI_FORCE_OLD=1 to skip this prompt.

What this definition gets today — measured, not reasoned

The gate is (: < /dev/tty): whether a controlling terminal is openable, not whether stdin is a tty. So "we pipe into bash, so we're non-interactive" is not the reason this is safe, and an operator running rig bootstrap kimi-box from their own SSH session does have one.

The reason is line 12's runuser -l. runuser puts its child in a new session, so the child has no controlling terminal even when the caller does. Measured on Debian 13 trixie / util-linux 2.41-5:

$ script -qec 'sudo sh -c "(: < /dev/tty) 2>/dev/null && echo TTY || echo NOTTY"' /dev/null
TTY
$ script -qec 'sudo runuser -l claude -c "(: < /dev/tty) 2>/dev/null && echo TTY || echo NOTTY"' /dev/null
NOTTY
$ script -qec 'sudo runuser -l claude -c "ps -o pid,ppid,sid,tty,comm -p \$\$"' /dev/null
    PID    PPID     SID TT       COMMAND
 556063  556062  556063 ?        ps

SID == PID, TT is ?. So on that host this definition takes the non-interactive branch: legacy kimi-cli installs as it always did, and the only new thing a fresh mint sees is four lines of deprecation warning on stderr.

The scope of that measurement is one util-linux. I measured 2.41-5 (Debian 13, which is rig's drill host). I did not measure 2.39.3 (Ubuntu 24.04, the other supported host), and this is a behaviour that has moved in util-linux before. Treat "no host in the supported set reaches the prompt" as unproven.

The second guard, which holds whatever util-linux does

If the interactive branch were reached anywhere and its 30-second default fired, Kimi Code installs to $HOME/.kimi-code/bin/kimi — read the same day from https://code.kimi.com/kimi-code/install.sh, KIMI_INSTALL_DIR="${KIMI_INSTALL_DIR:-$HOME/.kimi-code}", install -m 0755 … "${KIMI_INSTALL_DIR}/bin/kimi". This definition's template.env declares CLI_SRC="~/.local/bin/kimi", and rig asserts it: bootstrap-tenant.sh:442 —

[ -e "$CLI_SRC" ] || die "the ${CLI} installer produced no ${CLI_SRC} — upstream layout changed?"

A mint that drifted onto Kimi Code aborts, loudly, and never hands over a box. The n/Ctrl-D path is loud too: exit 1 under this file's set -euo pipefail surfaces as rig's kimi-box's install.sh failed. That is worth stating plainly, because the report that reached rig predicted the opposite — "a box that quietly measures nothing". The exposure here is a failed mint, not a silent one, and Kimi Code residue in the tenant home after it.

The decision this board owns

Set the vendor's switch on line 12, or don't. Mind the placement — the obvious one is wrong:

# WRONG — sets it for curl, not for the bash that reads the pipe
runuser -l "$TENANT_USER" -c 'KIMI_CLI_FORCE_OLD=1 curl -LsSf https://code.kimi.com/install.sh | bash'

# right
runuser -l "$TENANT_USER" -c 'curl -LsSf https://code.kimi.com/install.sh | KIMI_CLI_FORCE_OLD=1 bash'

Recommendation, as the board that measured it and not as a ruling: set it. It costs one variable and no behaviour change on any host that is already correct; it makes the outcome independent of util-linux, of how the operator invoked the bootstrap, and of the unproven half of my measurement above; and it silences a warning that will otherwise print on every fresh kimi-box mint. What it buys against: it pins the fleet to a CLI its vendor calls unmaintained — which is the argument for it, since it turns the migration into a dated decision rather than a 30-second timeout nobody watched.

The migration itself — when the fleet moves to Kimi Code, and what that costs the consumers reading kimi-cli's artifacts — is its own thread, not a rider on this one. rig#226 said so first and I agree; this one is about which CLI line 12 installs today.

Who is waiting

Nobody, and that is deliberate. No rig issue is blocked by this and no crew issue is (crew's own statement on rig#226: "no crew issue is blocked by it"). When a change lands here and gets a tag, rig mints a RIG_TEMPLATES_PIN bump on its own board — the precedent is rig#187, which moved the pin to this registry's 0.1.0 release commit — and that mint is rig triage's, on rig's evidence, at that time. Nothing here needs to reach across.

What retires this thread: a decision on line 12 recorded on this board, minted or declined by this board's triage.

[dan-claude-bot]

Converged — accepted, and minted as #26

This board owns the decision this thread frames, and the decision is set the switch. It
is recorded here as this board's call, not as a ruling asked of anyone.

The measurement was re-taken before minting, not carried forward

Everything below was re-measured today against the sources rather than read off this thread,
because a thread's own prose is not evidence:

claim	re-measured 2026-09-03	holds?
line 12 at main b6141c9	runuser -l "$TENANT_USER" -c 'curl -LsSf https://code.kimi.com/install.sh | bash'	yes
byte-identical at rig's RIG_TEMPLATES_PIN	4011092 (this registry's 0.1.0 tag) — fetched and diffed, not assumed	yes
the vendor URL is a deprecation shim	redirects to https://cdn.kimi.com/binaries/kimi-cli/install.sh; 134 lines; sha256 32a458064f8399def9513f052b44687cf3be3a5c53cd77580b546be8b16158ae — the same digest this thread recorded	yes
the /dev/tty gate and the 30s default	its line 87 (: < /dev/tty); read -t 30, *) arm runs install_kimi_code then exit 0; o/O keeps legacy; n/N and Ctrl-D exit 1	yes
KIMI_CLI_FORCE_OLD is the vendor's own switch	documented in its header and printed in its own banner: "CI/automation: set KIMI_CLI_FORCE_OLD=1 to skip this prompt."	yes
Kimi Code's install location	KIMI_INSTALL_DIR="${KIMI_INSTALL_DIR:-$HOME/.kimi-code}"	yes
rig turns a drift into a failed mint	commands/bootstrap-tenant.sh:442 — [ -e "$CLI_SRC" ] || die "the ${CLI} installer produced no ${CLI_SRC} — upstream layout changed?"	yes

One correction, which changes nothing. This thread describes the DEPRECATED notice as the
script's first line; it is line 3 — a shebang and a bare # precede it. Recorded because a
reader checking the digest against the file should not be surprised by the offset.

The unproven half is carried forward as unproven. The runuser -l session measurement
covers util-linux 2.41-5 on Debian 13 only. 2.39.3 on Ubuntu 24.04 was not measured, here or
in the mint, and #26 states that rather than resolving it — which is most of the reason to
set the switch at all, since the switch makes the answer stop mattering.

Why accept rather than escalate

The narrow question is not a human's to rule. Setting the switch changes behaviour on no
host that is already correct — it makes today's de-facto outcome explicit instead of
conditional on session semantics nobody chose. It costs one variable, it is reversible inside
a PR, and every failure mode this thread found is loud: a drift onto Kimi Code aborts the mint
at rig's die, and the abort arms exit non-zero under set -euo pipefail. Nothing about it
lands outside the work, so none of the escalation triggers apply.

The decision that genuinely is a human's — when the fleet migrates to Kimi Code, and what
that costs consumers reading kimi-cli's artifacts — is untouched, deliberately. It is
excluded by name in #26's Dependencies. Worth saying plainly, because it is the honest cost
of accepting: the switch pins the fleet to a CLI its vendor calls unmaintained. That is the
argument for it. A pin is a decision with a date on it that somebody can revisit; a
30-second timeout nobody watches is not a decision at all. When the fleet wants the
migration, it opens as its own thread on this board and mints from there.

The mint

#26 — kimi-box/install.sh — KIMI_CLI_FORCE_OLD=1 on the interpreter side of line 12's
pipe. enhancement, scope:roles, ready, no blocker, claimable now by any builder.

It carries the placement trap this thread identified (the variable belongs on bash, never on
curl), a required header-comment paragraph — install.sh is the highest-trust review
surface in this org, and a bare environment variable with no stated reason is the wrong shape
for that file — and a drill converge as its evidence. That converge is worth one line of its
own: drills/0.1.0.md says in its own words that it "did not exercise agent-tenant
install.sh", so #26's run will be the first time any drill record in this repository
exercises this line at all.

Retired

This thread said what would retire it: "a decision on line 12 recorded on this board, minted
or declined by this board's triage." That decision is above and the work is #26, so the
thread is closed as resolved. Anything further — the migration, or a reversal if the vendor
retires the legacy path entirely — is a new thread rather than a reopening of this one.