Summary

bunx oh-my-opencode doctor can terminate with exit code 137 and effectively do nothing, leaving users without actionable diagnostics.

Discord context

UltraWorkers Discord, #omo-help (1452487600647442464)

• message id: 1492522426469318756
• user report: ``bunx oh-my-opencode doctor exits with code 137; does nothing :/

This surfaced immediately after a release announcement that recommended:

bunx oh-my-opencode doctor

Repro shape

Exact environment is not yet confirmed, but the observed user flow is:

1. install/update oh-my-openagent / oh-my-opencode
2. run bunx oh-my-opencode doctor
3. command exits with code 137
4. user gets no useful health output / next-step diagnostics

Observed behavior

• exit code 137
• no actionable diagnostics
• user cannot tell whether the failure is:
  • OOM / process kill
  • install corruption
  • bad config
  • broken provider path
  • shell/runtime issue

Expected behavior

doctor should be the safest diagnostic entrypoint. Even when something goes wrong, it should:

• avoid silent/noisy hard failure where possible
• surface which stage failed
• emit actionable hints
• distinguish likely OOM/kill from config/runtime failures

Why this matters

doctor is being recommended publicly as the first recovery step. If it can fail with 137 and no explanation, users are thrown back into blind debugging at the exact point where the product promised clarity.

Possible improvement directions

• wrap child process failures with explicit stage labels
• catch/report signal-based exits (including 137) with explanation text
• add a lightweight/safe mode that avoids heavier checks when bootstrapping diagnostics
• print a final fallback block like:
  • what was being checked
  • which substep failed
  • what command to run next manually

Workaround

No confirmed workaround yet from the report.