Repository navigation
[Bug]: doctor repeats OPENCODEX_BUN_PATH guidance when a Bun canary override is already active #848
Description
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
- Install
@bitkyc08/opencodex@2.8.2-preview.20260731on Windows. - Set
OPENCODEX_BUN_PATHto Bun1.4.0-canary.1+5f65d3785and reinstall the service. - Confirm
ocx statusreportsRuntime source: override (OPENCODEX_BUN_PATH). - 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
devand 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.
Activity
github-actions commentedon Aug 1, 2026
Automated translation bookkeeping — detected language: unknown.
github-actions commentedon Aug 1, 2026
Issue reopened
The report now contains the information required by the automated check. Thanks for updating it.
luvs01 commentedon Aug 1, 2026
I evaluated a bounded implementation without opening a PR.
It leaves the conservative relay policy unchanged. Durable service artifacts bake only the
override|bundled|processsource enum;/api/system/memoryexposes 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 commentedon Aug 1, 2026
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, Windowsauto-known-badrepeats theOPENCODEX_BUN_PATHinstruction 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
devand open a focused PR againstdevwith these corrections before review:override | bundled | processprovenance marker through every actual launcher: the npm Node launcher, Windows scheduler, Windows native WinSW, launchd, and systemd.durableBunRuntime()at reporting time and guess from the current shell, because that can mislabel the already-running process.bunRevisioninformational only and preserve the conservativeauto-known-badresult for canaries.OPENCODEX_BUN_PATH”.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.
fix(doctor): report how the service actually got its Bun runtime
docs(plan): allocate 12 must-fix bugs across 5 bugfix worktrees
test(memory): give the #848 provenance test headroom on slow CI runners
lidge-jun commentedon Aug 2, 2026
Fixed in #892 (wt5). The service records its Bun runtime provenance as a source+path pair through every launcher; doctor reads that marker and identifies an active OPENCODEX_BUN_PATH override instead of repeating the set-up instruction — src/cli/doctor.ts:665-679 names this issue, with regression coverage in tests/memory-watchdog.test.ts ("serializes only an allowlisted Bun runtime provenance, omitting it otherwise (#848)").
docs(plan): allocate 12 must-fix bugs across 5 bugfix worktrees
fix(doctor): report how the service actually got its Bun runtime
test(memory): give the lidge-jun#848 provenance test headroom on slow…
test(memory): cover the #848 provenance matrix on the pure function, …
test(server): widen #848 provenance route budget for saturated macOS …
test(server): stop paying for eight route snapshots in the #848 prove…
ci: retrigger to pick up dev's lidge-jun#848 provenance-test fix