Skip to main content

​
Doctor And Health

Loong uses doctor as the main repair path when the base runtime is unhealthy.

​
Start Here

If you need to…Start with
check the local runtime health quicklyloong doctor
apply the safe repair pathloong doctor --fix
feed health output into another tool or scriptloong doctor --json
inspect the security-oriented checks onlyloong doctor security
keep a live developer watch on one runtime/sessionloong debug watch --config <path> --session-id <session>
capture one deeper developer/debug bundleloong debug bundle --config <path> --session-id <session>

​
Core Commands

loong doctor
loong doctor --fix
loong doctor --json
loong doctor security
loong doctor security --json
loong debug watch --config /path/to/loong.toml --session-id session-123
loong debug watch --config /path/to/loong.toml --session-id session-123 --refresh-ms 1000
loong debug bundle --config /path/to/loong.toml --session-id session-123
loong debug bundle --config /path/to/loong.toml --session-id session-123 --output /tmp/debug-bundle.json
loong debug show --artifact /tmp/debug-bundle.json

​
When To Escalate To Audit

loong audit recent --limit 20
loong audit summary --limit 200 --json
loong audit token-trail --token-id token-abc
Use the audit commands when:
  • the runtime looks unhealthy and you need recent operator-visible evidence
  • a repair action happened but you want to inspect what changed
  • policy or token flow needs a more explicit trail than doctor alone provides

​
When To Escalate To Debug Bundle

loong debug watch --config /path/to/loong.toml --session-id session-123
loong debug bundle --config /path/to/loong.toml --session-id session-123
loong debug bundle --config /path/to/loong.toml --session-id session-123 --output /tmp/debug-bundle.json
loong debug show --artifact /tmp/debug-bundle.json
Use the debug bundle when:
  • you need a live, continuously refreshed view over one active runtime or session before you decide whether to capture a point-in-time artifact
  • the runtime is behaving incorrectly and you need one combined view over status, ACP, session, provider failover, and audit evidence
  • you want to hand one artifact to another maintainer without asking them to rebuild the same local inspection steps
  • you need request ids, failover rollups, session recovery state, and audit integrity in one place

​
What This Page Optimizes For

  • keep health issues legible for operators
  • prefer safe local repair actions
  • surface concrete next steps instead of vague status-only output
  • preserve audit visibility for policy and runtime debugging

​
When To Use It

  • after onboarding if credentials or config still feel incomplete
  • before enabling channels or gateway surfaces
  • when runtime behavior has drifted and you need a trustworthy repair path

​
Typical Order

  1. Run loong doctor.
  2. Run loong doctor --fix if the safe repair path is appropriate.
  3. Use loong debug watch when you need live counters, recent session events, and failover/audit attention while the issue is still happening.
  4. Capture loong debug bundle when you need a stable artifact to share or compare later.
  5. Use audit commands when you need evidence or a deeper governance trail.
  6. Return to First Run once the base path is healthy again.

​
What Comes Next

  • Return to First Run if you still have not reached a first useful answer.
  • Continue to Skills when the blocker is install policy, skill exposure, or browser automation setup.
  • Continue to Browser And Web Boundaries when the blocker is a private host, domain allowlist, or browser runtime gate.
  • Move on to Use Loong once the base local runtime is healthy.