fix(cli): use system ripgrep in packaged builds

[Hardik180704]

Summary

• redirect Morph's optional @vscode/ripgrep import to its existing PATH-based fallback in compiled CLI builds
• keep normal source and development installs unchanged
• add patch changesets for the CLI and VS Code extension

Why

The VS Code extension bundles a compiled CLI without a node_modules tree. Morph's local code-search provider attempted to resolve a platform-specific optional package before its system-ripgrep fallback could run, producing a runtime error on macOS ARM64.

Validation

• CLI typecheck passed with the repository-required Bun 1.3.14
• packaged macOS ARM64 CLI build and smoke checks passed
• rebuilt binary no longer contains the missing optional-dependency error path
• annotation guard and lint passed (0 errors)

Fixes #12787

[kilo-code-bot]

Code Review Summary

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/tool/warpgrep.ts	50	The new yield* ripgrep.filepath preflight runs on every codebase_search, including source/dev runs where the script/build.ts redirect is not applied and Morph resolves its own @vscode/ripgrep. Because execute ends in Effect.orDie, a provisioning failure (blocked GitHub release download, extraction error, unsupported arch/platform) becomes a defect instead of a tool error, breaking a search that previously worked. Consider Effect.ignore or a catchAll that returns the normal output shape

Files Reviewed (3 files in incremental diff)

• packages/opencode/src/tool/warpgrep.ts - 1 issue
• packages/opencode/src/kilocode/morph-ripgrep.ts - no issues
• packages/core/src/ripgrep.ts - no issues

Both previous findings on morph-ripgrep.ts are resolved: the shim now skips which("rg") on Windows, matching RipgrepBinary.filepath's deliberate avoidance of Git-for-Windows' MSYS rg.exe, and the managed-fallback timing is now guaranteed by the new preflight. I traced all four resolution cases (system rg present/absent, Windows/non-Windows) and the shim's rgPath agrees with RipgrepBinary.filepath in each, helped by which() already including Global.Path.bin in its search path. Ripgrep.Service has exactly one implementation, so widening Interface with filepath breaks no other layer, and it is available in the tool-registry graph (registry.ts:423), so the warpgrep.ts dependency resolves. The two added lines in the shared packages/core/src/ripgrep.ts are a minimal marked hook rather than a restructure. Review was performed without an installed node_modules tree, so Morph's exact use of rgPath (whether it stats before spawning) could not be confirmed directly.

Fix these issues in Kilo Cloud

Previous Review Summaries (2 snapshots, latest commit e86d98b)

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

Previous review (commit e86d98b)

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	8	which("rg") is called unconditionally, including on Windows, where RipgrepBinary.filepath (packages/core/src/ripgrep/binary.ts:94-96) deliberately ignores a system rg because Git for Windows may expose an incompatible MSYS rg.exe; mirroring that guard keeps both resolvers consistent. Also worth documenting that the Global.Path.bin fallback is only valid once the managed download has run, since which() already searches that directory

Files Reviewed (1 file in incremental diff)

• packages/opencode/src/kilocode/morph-ripgrep.ts - 1 issue

The previous review's finding about the bare rg string is resolved: the shim now resolves through which() with a Global.Path.bin fallback. The build-plugin approach remains well scoped for fork hygiene — one plugin registration in script/build.ts, replacement module under src/kilocode/. Verified that @opencode-ai/core exposes ./global and ./util/which via its "./*" export map. Review was performed without an installed node_modules tree, so Morph's exact consumption of rgPath (whether it stats the path before spawning, and whether it retains a PATH fallback) could not be confirmed directly.

Fix these issues in Kilo Cloud

Previous review (commit 2077f02)

Status: 1 Issue Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	1
SUGGESTION	0

Issue Details (click to expand)

WARNING

File	Line	Issue
packages/opencode/src/kilocode/morph-ripgrep.ts	4	Shim hardcodes a bare rg on PATH, which packaged macOS/Windows users often lack; Kilo already resolves ripgrep via which("rg") plus a managed download in Global.Path.bin (packages/core/src/ripgrep/binary.ts), so pointing the shim there would cover both cases

Files Reviewed (3 files)

• .changeset/quiet-ripgrep-packaging.md - 0 issues
• packages/opencode/script/build.ts - 0 issues
• packages/opencode/src/kilocode/morph-ripgrep.ts - 1 issue

The build-plugin approach itself looks well scoped for fork hygiene: the shared-file change is a single plugin registration in script/build.ts, and the replacement module lives under src/kilocode/. Note the review was done without an installed node_modules tree, so Morph's exact @vscode/ripgrep import shape and fallback behavior could not be verified directly; the dependency edge was confirmed from bun.lock.

Fix these issues in Kilo Cloud

---

_{Reviewed by claude-opus-5 · Input: 44 · Output: 12.1K · Cached: 1.2M}

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

[marius-kilocode]

@Hardik180704 please stop the automation on our issues. We need high quality contributions where implementation and functionality was verified by a human. Thanks.

[Hardik180704]

Understood, and I apologize. I’ll stop the automated issue-claiming and PR activity on the repository. I appreciate the feedback, and I’ll ensure that any future contribution is personally reviewed and functionally verified by me before I post or open anything. Thank you for clarifying your expectations.

[Hardik180704]

@marius-kilocode, if you have the time, could you please take one final look at my currently open PRs? Please feel free to close any that do not meet the project’s quality standards. I completely understand and will respect your judgment. There is no obligation to review them immediately, and I will not submit further automated contributions. Thank you.

[marius-kilocode]

@Hardik180704 please manually test all of your PR's and post proof. I won't review a PR that hasn't been tested/reviewed by the contributor.

[Hardik180704]

@marius-kilocode
Understood. I’ll personally review each open PR and manually test the affected functionality before requesting further review. I’ll post clear reproduction and verification evidence on each PR, and I’ll close any PR that I cannot confidently verify or explain. Thank you for the clarification.

[johnnyeric]

Thanks for the contribution! Closing this PR as it was superseded by #13084.