Windows: grep tool fails to detect installed ripgrep and tar ("Neither ripgrep (rg) nor GNU grep is available")

Environment

• OS: Windows 11 Pro (build 26200), x64
• opencode-bettergrep: 1.2.1 (latest as of today)
• opencode server is launched by an external terminal workspace manager (herdr), not from an interactive shell
• ripgrep 15.1.0 installed via winget; its package dir is on the user PATH (...\WinGet\Packages\BurntSushi.ripgrep.MSVC_...\ripgrep-15.1.0-x86_64-pc-windows-msvc)
• tar: Windows built-in C:\Windows\System32\tar.exe (bsdtar 3.8.9)

Symptom

Every grep tool call fails with:

Neither ripgrep (rg) nor GNU grep is available. Checked system rg, managed rg, ripgrep auto-install, and system grep. Auto-install error: ripgrep auto-install requires tar on this Windows host to extract zip archives.

This happens consistently, across sessions.

What I verified

From a child process spawned by the same opencode server (a PowerShell tool process), I replicated the plugin's probes exactly, with Node:

const { spawnSync } = require('child_process');
spawnSync('rg',  ['--version'], { stdio: ['ignore','pipe','pipe'], timeout: 5000 }) // status=0, "ripgrep 15.1.0"
spawnSync('tar', ['--version'], { stdio: ['ignore','pipe','pipe'], timeout: 5000 }) // status=0, "bsdtar 3.8.9"

Both resolve and execute in under 100ms with exit code 0. rg is on PATH; tar lives in System32. Yet the plugin's resolver reports both as unavailable.

So the environment the resolver probes in (the long-lived opencode server process) appears to differ from the environment its own child processes see — most likely the server's PATH snapshot taken at launch (the server here is started by an external manager, not a login shell). Once which rg / hasCommand("tar") fail inside the server process, nothing downstream can recover: the managed copy doesn't exist yet, and auto-install is gated on the same failing tar probe.

Workaround that works

Manually populating the managed cache dir:

%LOCALAPPDATA%\opencode-bettergrep\grep\bin\rg.exe
%LOCALAPPDATA%\opencode-bettergrep\grep\bin\.ripgrep-metadata.json

with metadata:

{"version":"15.1.0","assetName":"rg.exe","binarySha256":"<lowercase sha256 hex of rg.exe>"}

The managed candidate is executed by absolute path, so it bypasses the broken PATH lookup entirely. After doing this, grep worked immediately (verified in the same session that was failing).

Note for anyone copying this workaround: assertBinarySha256 compares against lowercase hex from digest("hex"); PowerShell's Get-FileHash outputs uppercase, so lower-case it first.

Suggestions

1. An explicit escape hatch — an env var like BETTERGREP_RG_PATH (or an opencode config option) pointing at an rg binary, validated via absolute path. That would turn this class of problem into a one-liner instead of hand-crafting sha256 metadata files.
2. Diagnosable failures — when the resolver gives up, include in the error: the process.env.PATH it saw, and what each probe (system rg / managed rg / tar / grep) actually returned. Right now the message gives no hint that the binaries are in fact installed and working in child processes of the very same server.
3. On Windows, consider probing tar via its well-known absolute path (%SystemRoot%\System32\tar.exe) as a fallback before declaring auto-install impossible.