Skip to content

Improve Kimi Code runtime discovery - #3084

Open
ninjusai wants to merge 1 commit into
block:mainfrom
ninjusai:feat/kimi-runtime
Open

Improve Kimi Code runtime discovery#3084
ninjusai wants to merge 1 commit into
block:mainfrom
ninjusai:feat/kimi-runtime

Conversation

@ninjusai

Copy link
Copy Markdown

Summary

  • probe Kimi Code's standalone ~/.kimi-code/bin install directory so GUI-launched Desktop processes can resolve kimi
  • keep the Kimi preset on kimi acp and point its setup guidance to the official Kimi Code CLI documentation
  • document the harness configuration and add regression coverage for discovery and preset arguments

Tests

  • cargo fmt --manifest-path desktop/src-tauri/Cargo.toml -- --check
  • cargo test --manifest-path desktop/src-tauri/Cargo.toml kimi -- --test-threads=1 — 2 passed
  • full serial Tauri suite — 1,693 passed, 10 ignored; the existing order-dependent managed_agents::runtime::tests::claude_spawn_uses_the_probed_cli_executable test failed in-suite and passed immediately in isolation on the same commit

Co-authored-by: ninjusai <192658217+ninjusai@users.noreply.github.com>

Signed-off-by: ninjusai <192658217+ninjusai@users.noreply.github.com>
@linxule

linxule commented Jul 28, 2026

Copy link
Copy Markdown
Contributor

One data point on the discovery path, in case it's useful for scoping this.

I hit this exact symptom (Kimi Code showing "CLI needed" on a GUI-launched Buzz while kimi worked fine in a terminal), but ~/.kimi-code/bin wouldn't have resolved it. Kimi Code also ships as an npm package (@moonshot-ai/kimi-code), so a bun add -g / npm-global install puts the executable in the package manager's bin dir instead:

$ ls ~/.kimi-code/bin
rg

$ command -v kimi
/Users/…/.bun/bin/kimi -> ../install/global/node_modules/@moonshot-ai/kimi-code/dist/main.mjs

~/.kimi-code exists and holds config/credentials/cache, but bin/ only has a vendored rg — no kimi. So the standalone-installer probe here and the package-manager install route are two separate cases.

The underlying cause is the same one this PR's comment describes, and it isn't Kimi-specific: ~/.bun/bin isn't in common_binary_paths(), and bun's installer writes its PATH export to ~/.zshrc (interactive), so find_via_login_shell() can't recover it either — same as the nvm situation already documented in resolve_command_uncached.

I opened #3343 to add ~/.bun/bin to common_binary_paths(), which should be complementary to this rather than overlapping: this PR covers the standalone installer, that one covers bun-installed CLIs generally (it fixed Codex on my machine too, for the same reason).

wpfleger96 pushed a commit that referenced this pull request Jul 29, 2026
## Problem

`common_binary_paths()` probes mise shims, `~/.local/bin`, volta, asdf,
and (further down `resolve_command_uncached`) nvm's default bin dir —
but not bun's global bin directory, `~/.bun/bin`.

bun's installer appends its bin dir to `~/.zshrc` / `~/.bashrc`, which
are **interactive**-only. A login shell never sources them, so
`find_via_login_shell()` can't recover the path either. That's the same
failure mode already called out in this file for nvm:

```rust
// Check nvm's default Node.js bin directory — nvm initializes via
// ~/.zshrc (interactive) which is not loaded by a login shell, so
// `node`, `npm`, and npm-global shims installed there are otherwise
// invisible.
```

So for a GUI-launched desktop app, every rung of the resolution ladder
misses a bun-installed CLI:

1. workspace dev dirs — no
2. `command_looks_like_path` — no, presets use bare names
3. Buzz-managed npm/node dirs — no
4. current process PATH — launchd's minimal PATH on a Finder launch
5. `find_via_login_shell` — `.zshrc` not sourced
6. `common_binary_paths()` — **`~/.bun/bin` absent**
7. nvm default bin — no

This matters because bun is a common install route for the agent CLIs
Buzz targets. Kimi Code in particular ships as an npm package
(`@moonshot-ai/kimi-code`), so `bun add -g` puts it at `~/.bun/bin/kimi`
— exactly where discovery doesn't look.

## Reproduction

On macOS with `codex` and `kimi` installed via bun, launching Buzz from
Finder:

- Kimi Code shows **"CLI needed"**
- both CLIs run fine in an interactive terminal

Probing the way `find_via_login_shell` does, in a clean environment:

```console
$ env -i HOME=$HOME /bin/zsh -l -c 'command -v -- codex; command -v -- kimi'
(nothing)
```

Launching the app with the bun dir on PATH resolves both immediately:

```console
$ env PATH="$HOME/.bun/bin:$PATH" /Applications/Buzz.app/Contents/MacOS/buzz-desktop
```

## Change

One entry appended to the home-relative list in `common_binary_paths()`.
It goes **last** so it cannot shadow a directory that already resolves —
the change can only add resolutions, never alter existing ones.

## Testing

`cargo fmt --check` passes.

I was not able to run the full `just ci` gate locally: `ring 0.17.14`
fails to build in this environment against the macOS 26.2 SDK (`cc`
error compiling `p256-nistz.c`), which is unrelated to this change.
Relying on CI for the rest — the diff adds one `PathBuf` to an existing
`Vec<PathBuf>` and introduces no new API.

## Notes

- Related to #3084, which adds `~/.kimi-code/bin` for the same class of
GUI-launch discovery failure. That covers Kimi's standalone installer;
this covers the bun/npm-global install route. They're complementary —
I've left a note on that PR.
- Only `~/.bun/bin` is added. bun's global packages live under
`~/.bun/install/global/node_modules` but are symlinked into
`~/.bun/bin`, so the single directory is sufficient.
- Worth noting `~/.bun/bin` contains no `node`/`npm`/`npx`, so appending
it can't shadow a system Node toolchain.

Signed-off-by: Xule Lin <43122877+linxule@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants