fix(cli): use managed ripgrep in packaged builds

[johnnyeric]

Issue

Fixes #12787

Context

Packaged Kilo binaries do not ship a node_modules tree, but Morph's WarpGrep client imports @vscode/ripgrep, which resolves a platform-specific optional package at module load. On macOS ARM64 this crashes codebase search before Morph or Kilo can fall back to another ripgrep binary.

Implementation

The packaged CLI build aliases only @vscode/ripgrep to a Kilo-owned shim that selects a compatible system rg or Kilo's managed cache path. Before invoking Morph, codebase_search provisions that path through RipgrepBinary.Service.

The tool registry declares the binary service directly because transitive Effect layer dependencies are not exposed to consumers. Provisioning failures and defects are returned as normal zero-result tool output instead of crashing the tool.

Screenshots / Video

N/A

How to Test

Manual/local verification

• Agent: compiled the original loader as a standalone binary and reproduced the exact @vscode/ripgrep-darwin-arm64 failure with exit code 1.
• Agent: compiled the same import through the Kilo build plugin under the same no-system-rg, no-runtime-node_modules conditions; it exited 0 and resolved Kilo's managed cache path.
• Agent: built the native macOS ARM64 standalone CLI with bun run script/build.ts --single --skip-install and initialized its real tool registry through the compiled server.
• Agent: ran bun test ./test/kilocode/tool/warpgrep-ripgrep-provisioning.test.ts — 2 passed.
• Agent: the pre-push repository typecheck passed for all packages, including JetBrains with Java 21.
• Agent: annotation, Promise-facade, formatting, diff, and lint guards passed.

Reviewer test steps

1. From packages/opencode, run bun test ./test/kilocode/tool/warpgrep-ripgrep-provisioning.test.ts.
2. Build the current platform binary with bun run script/build.ts --single --skip-install.
3. On macOS ARM64, launch the packaged CLI or extension without a system rg on PATH and with an empty Kilo binary cache.
4. Invoke codebase_search and confirm it provisions ripgrep instead of reporting a missing @vscode/ripgrep-darwin-arm64 package.

Checklist

• Issue linked above, or exception explained
• Tests/verification described
• Screenshots/video included for visual changes, or marked N/A
• Changeset considered for user-facing changes
• I personally reviewed the diff and can explain the changes, including any AI-assisted work.

Get in Touch

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7844d5dc9f

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Incremental review of 7844d5d..a2382e5: the new commits resolve all three previous findings — the managed-binary path is now a single shared constant (packages/core/src/kilocode/ripgrep-binary.ts), the provisioning logic moved into the Kilo mirror src/kilocode/tool/warpgrep.ts behind one marked hook in the shared tool file, and provisioning is gated to packaged builds via the KILO_MORPH_RIPGREP_MANAGED define so source/dev and node builds keep Morph's own @vscode/ripgrep. The shim alias and the define live in the same Bun.build call, so they stay in sync. Tests cover both modes against the real Provision implementation, and no new subscriptions, handles, or caches are introduced — provisioning reuses the memoized Effect.cached binary service.

Files Reviewed (10 files)

• .changeset/fix-packaged-codebase-search.md
• packages/core/src/kilocode/ripgrep-binary.ts
• packages/core/src/ripgrep/binary.ts
• packages/opencode/script/build.ts
• packages/opencode/script/kilocode/morph-ripgrep.ts
• packages/opencode/src/kilocode/morph-ripgrep.ts
• packages/opencode/src/kilocode/tool/warpgrep.ts
• packages/opencode/src/tool/registry.ts
• packages/opencode/src/tool/warpgrep.ts
• packages/opencode/test/kilocode/tool/warpgrep-ripgrep-provisioning.test.ts

Previous Review Summary (commit 7844d5d)

Current summary above is authoritative. Previous snapshots are kept for context only.

Previous review (commit 7844d5d)

Status: 1 Issue Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	0
SUGGESTION	1

Issue Details (click to expand)

SUGGESTION

File	Line	Issue
packages/opencode/src/kilocode/morph-ripgrep.ts	5	Managed-binary fallback path duplicates the download target in RipgrepBinary (packages/core/src/ripgrep/binary.ts); extract a shared constant so the two cannot drift

The fix is well-scoped: the build-time alias and runtime provisioning agree on the managed path in all stable-environment scenarios (system rg, cached managed rg, first-run download, Windows carve-out), failures degrade to zero-result tool output instead of crashing, fork hygiene is good (logic in kilocode dirs, minimal marked hooks in shared files), tests exercise the real tool and the real build plugin, and a changeset is included. No memory-leak concerns: no new subscriptions, handles, or unbounded caches — provisioning reuses the existing Effect.cached binary service.

Fix these issues in Kilo Cloud

Files Reviewed (7 files)

• .changeset/fix-packaged-codebase-search.md
• packages/opencode/script/build.ts
• packages/opencode/script/kilocode/morph-ripgrep.ts
• packages/opencode/src/kilocode/morph-ripgrep.ts - 1 issue
• packages/opencode/src/tool/registry.ts
• packages/opencode/src/tool/warpgrep.ts
• packages/opencode/test/kilocode/tool/warpgrep-ripgrep-provisioning.test.ts

---

_{Reviewed by kimi-k3 · Input: 110.7K · Output: 16.7K · Cached: 1M}

_{Review guidance: REVIEW.md from base branch main}

[chrarnoldus]

Morph's WarpGrep

should we remove this instead? It is constantly causing issues and is (should be) an optional community contribution (#6685)

[johnnyeric]

Thanks for the context, given that I think it would make sense to remove, I am taking a deeper look at how it is implemented.

[johnnyeric]

Superseded by #13084