Problem
Telemetry from 2026-05-21 (memory/telemetry-analysis-2026-05-21.md, 2,503 machines, 14 days) shows project_scan failing 32% of the time (437/1,366 calls). 1,171 distinct users hit this — the broadest user-impact bug in the dataset by a wide margin. Every failure has the same fingerprint: Executable not found in $PATH: ?.
project_scan is the first-interaction tool — it runs when the agent boots and discovers the data environment. A 32% failure rate at first-interaction is a major conversion killer for new installs.
Root cause (two-part)
-
detectGit() in packages/opencode/src/altimate/tools/project-scan.ts:50-75 calls Bun.spawnSync(["git", ...]) without any try/catch. Bun's spawnSync THROWS when the binary is missing from PATH, not just when it exits non-zero. So in any environment without git (some Docker containers, fresh Windows installs without Git for Windows, minimal Alpine images), the entire project_scan tool crashes — even though dbt detection, env-var detection, and the other sub-detections don't depend on git.
-
The PII masker shreds the diagnostic. Bun.spawnSync throws Executable not found in $PATH: "git". The telemetry masker in telemetry/index.ts:1083-1084 strips quoted strings to ?, leaving the un-debuggable Executable not found in $PATH: ? we see in production.
detectDataTools() already has try/catch around its Bun.spawnSync (line 354), so it doesn't crash on missing tools. detectGit() was the only crasher.
Fix
Two parts:
- Wrap every
Bun.spawnSync in detectGit() with a shared safeSpawnSync helper that returns null instead of throwing when the binary is missing.
- Wrap every detection in
project_scan.execute() with .catch() that records the failure to a degraded: string[] field and continues. The tool now always succeeds with partial results; the LLM can see exactly what was missing in both the formatted output and the metadata.
This is the "make tool infallible with degraded: [...] field" recommendation from the P0 triage doc (docs/internal/2026-05-21-p0-triage.md).
Impact
Should drop the project_scan error rate from 32% to near-zero. Users without git installed will get a successful scan that notes "git" in the degraded list, instead of a hard failure with a masked error.
Problem
Telemetry from 2026-05-21 (
memory/telemetry-analysis-2026-05-21.md, 2,503 machines, 14 days) showsproject_scanfailing 32% of the time (437/1,366 calls). 1,171 distinct users hit this — the broadest user-impact bug in the dataset by a wide margin. Every failure has the same fingerprint:Executable not found in $PATH: ?.project_scanis the first-interaction tool — it runs when the agent boots and discovers the data environment. A 32% failure rate at first-interaction is a major conversion killer for new installs.Root cause (two-part)
detectGit()inpackages/opencode/src/altimate/tools/project-scan.ts:50-75callsBun.spawnSync(["git", ...])without any try/catch. Bun's spawnSync THROWS when the binary is missing from PATH, not just when it exits non-zero. So in any environment without git (some Docker containers, fresh Windows installs without Git for Windows, minimal Alpine images), the entireproject_scantool crashes — even though dbt detection, env-var detection, and the other sub-detections don't depend on git.The PII masker shreds the diagnostic.
Bun.spawnSyncthrowsExecutable not found in $PATH: "git". The telemetry masker intelemetry/index.ts:1083-1084strips quoted strings to?, leaving the un-debuggableExecutable not found in $PATH: ?we see in production.detectDataTools()already has try/catch around itsBun.spawnSync(line 354), so it doesn't crash on missing tools.detectGit()was the only crasher.Fix
Two parts:
Bun.spawnSyncindetectGit()with a sharedsafeSpawnSynchelper that returnsnullinstead of throwing when the binary is missing.project_scan.execute()with.catch()that records the failure to adegraded: string[]field and continues. The tool now always succeeds with partial results; the LLM can see exactly what was missing in both the formatted output and the metadata.This is the "make tool infallible with
degraded: [...]field" recommendation from the P0 triage doc (docs/internal/2026-05-21-p0-triage.md).Impact
Should drop the
project_scanerror rate from 32% to near-zero. Users without git installed will get a successful scan that notes "git" in thedegradedlist, instead of a hard failure with a masked error.