Skip to content

support / local-first diagnostics

Get unstuck without exposing your work.

WaitDojo support begins with local, reviewable diagnostics. No support bundle is uploaded automatically, and you decide what leaves your machine.

Invitation and sign-in help.

The installer is public. Downloading or running it does not grant invited beta access.

A private invitation claim binds one invitation to a GitHub account and creates an access entitlement. Sign in with that same account. Beta-gated builds check access at launch and can use a valid cached confirmation for up to seven days. Online confirmations are refreshed after 24 hours when WaitDojo next checks them. A revoked account is denied when a later launch refreshes that confirmation. A drill already in progress is never interrupted by an access check.

The published v0.2.6 archives enforce these launch checks. Older v0.2.4 archives predate the invitation gate and do not create an entitlement. Use the current release for the invited beta.

If a claim fails, describe the status shown on the clean claim page. Never paste an invitation link or claim value into a support message.

Start with the product doctor.

Terminalbash
waitdojo doctor --product

Use the linked WDOJO_* code to jump to the exact remediation on the doctor guide.

Preview before sharing.

Terminalbash
waitdojo support-bundle --preview
waitdojo support-bundle --explain-redactions

The bundle reports product version, coarse platform kind, command availability, terminal dimensions, path kinds, stable error codes, and remediation text. It excludes full home paths, usernames, PATH, prompts, code, agent output, tokens, and secret values.

Product provenance.

Preview a clean uninstall.

Terminalbash
waitdojo uninstall --dry-run
waitdojo uninstall

The default uninstall removes managed hooks, tmux control state, PATH entries, and the binary while keeping local progress and settings. Add --remove-data only when you also want WaitDojo's local progress, settings, backups, and support files deleted.

What to include in a support message.

Details
  • WaitDojo version and whether you selected Codex or Claude Code.
  • macOS, Linux, or WSL2 and the stable WDOJO_* error code.
  • The reviewed, redacted doctor output or support-bundle preview.

Do not send prompts, repository contents, tokens, full paths, or coding-agent output.