[Bug]: doctor repeats OPENCODEX_BUN_PATH guidance when a Bun canary override is already active

[luvs01]

Client or integration

OpenCodex CLI (ocx doctor, npm packaged install)

Area

CLI / Bun runtime diagnostics

Summary

ocx doctor can tell Windows users to set OPENCODEX_BUN_PATH even when the running service already uses that override. This makes the guidance circular and obscures the difference between the bundled runtime and an explicitly selected, unvalidated canary.

Reproduction

1. Install @bitkyc08/opencodex@2.8.2-preview.20260731 on Windows.
2. Set OPENCODEX_BUN_PATH to Bun 1.4.0-canary.1+5f65d3785 and reinstall the service.
3. Confirm ocx status reports Runtime source: override (OPENCODEX_BUN_PATH).
4. Run ocx doctor.

It reports Bun 1.4.0, auto-known-bad, then suggests setting OPENCODEX_BUN_PATH to a trusted runtime.

The same wording remains on current dev. src/cli/doctor.ts explicitly notes that the endpoint cannot distinguish a bundled binary from an override with the same version. The service already reports bunRevision; the installed revision is 941 commits ahead of, and 0 behind, the merge commit of oven-sh/bun#32120. This does not require OpenCodex to trust every canary automatically, but it demonstrates why version-only wording is incomplete.

Expected behaviour

Keep the conservative stream policy, but make diagnostics runtime-origin aware:

• bundled known-bad runtime: retain the override suggestion;
• active override: say the override is active but remains unvalidated for automatic eager relay, without suggesting the already completed action.

Including bunRevision in the displayed identity would make reports actionable.

Regression coverage

Cover both bundled and override runtimes with the same reported version. The bundled case should offer OPENCODEX_BUN_PATH; the override case should identify the active override and not repeat that instruction.

Version

2.8.2-preview.20260731 (gitHead a5f48e31052fd28547bf383ebc47c9303fa74eaa)

Operating system

Windows 11 Pro 25H2, build 26200.8875, x64

Checks

• Reproduced with the packaged preview and live service.
• Confirmed the proxy process uses the configured canary executable.
• Checked current dev and searched existing issues/PRs.
• Related to [Bug]: npm launcher ignores OPENCODEX_BUN_PATH for direct starts and update fallbacks #721/fix(launcher): honor OPENCODEX_BUN_PATH #734, but runtime selection itself is working correctly.

[github-actions]

_{Automated translation bookkeeping — detected language: unknown.}

[github-actions]

Issue reopened

The report now contains the information required by the automated check. Thanks for updating it.

[luvs01]

I prepared a fork-only experiment (no upstream PR yet): branch, commit b2d11043.

It leaves the conservative relay policy unchanged. Durable service artifacts bake only the override|bundled|process source enum; /api/system/memory exposes that optional scalar plus the existing revision; and doctor retains bundled-runtime guidance while identifying an active override without repeating its setup instruction.

Focused validation: 90/90 tests passed on bundled Bun 1.3.14 and Bun 1.4 canary; typecheck passed. I will wait for maintainer direction before opening a PR.

[Ingwannu]

Confirmed on current dev@fa5780d5: this is a real diagnostics bug. The service/doctor path has the Bun version (and the management payload already exposes the revision), but it has no trustworthy runtime-origin field. As a result, Windows auto-known-bad repeats the OPENCODEX_BUN_PATH instruction even when the override is already active.

I also checked b2d1104314eb471d7d1cb7b67dd4cf8f2546f3dd. The overall direction is right, and this must remain diagnostics-only—please do not change the conservative eager-relay capability policy for canary/unknown Bun builds.

Please rebase that work onto current dev and open a focused PR against dev with these corrections before review:

• Propagate one allowlisted override | bundled | process provenance marker through every actual launcher: the npm Node launcher, Windows scheduler, Windows native WinSW, launchd, and systemd.
• When a legacy service/payload has no provenance marker, report it as unknown/absent. Do not call durableBunRuntime() at reporting time and guess from the current shell, because that can mislabel the already-running process.
• Keep bunRevision informational only and preserve the conservative auto-known-bad result for canaries.
• Add regressions covering scheduler + WinSW + launchd + systemd + the direct Node launcher, old payloads without the new field, and override wording that does not repeat “set OPENCODEX_BUN_PATH”.
• Document the provenance trust and backward-compatibility rule in structure/05_gui-and-management-api.md.

The current focused doctor/runtime/service/watchdog baseline passes 99/99 tests. With the items above, the existing experiment should be ready for PR review; there is no need to redo the rest of it. I’ll leave this issue open pending that PR.