Skip to content

privacy contract / product + website

Your code stays yours.

WaitDojo needs lifecycle timing, not your work. Practice data stays local by default. Invited-beta access requires a claimed invitation and GitHub sign-in; access checks and activity uploads are separate.

Product data stays local by default.

WaitDojo stores activity progress, timestamp-and-event lifecycle rows, configuration, backups, a local telemetry queue, and support bundles below ~/.codex/waitdojo/ by default. In the published v0.2.6 release, local telemetry can be disabled with:

Terminalbash
waitdojo config set telemetry_mode off

Local telemetry never includes prompt text, quiz answers, coding-agent output, tmux pane text, file paths, usernames, environment variables, tokens, or file contents.

Waitlist and invitation claims are separate from product sync.

Joining the invited-beta waitlist stores a normalized email address and fixed signup source. If invited, the site persists SHA-256 hashes of the invitation, claim-session, and OAuth-state secrets. The entitlement record includes the Supabase user ID bound to the GitHub account, waitlist email, status, invitation and claim timestamps, and optional access expiry.

Raw invitation values are not written to application logs, page content, funnel events, or database rows.

The site-side access entitlement is separate from remote activity uploads. Claiming an invitation on this website does not upload local activity or change the product's telemetry settings. Beta-gated builds check the signed-in account's own entitlement and keep an unsigned local access 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; active drills are not interrupted. Offline access ends when the confirmation expires, so revocation is not immediate for an offline device.

The access confirmation is stored in ~/.codex/waitdojo/beta-lease.json. It contains the Supabase project URL, user ID, access status, optional access expiry, and last confirmation time. Signing out or uninstalling with --remove-data deletes it. Access checks do not send prompts, code, or activity content.

Hooks are passive lifecycle signals.

Codex and Claude Code invoke WaitDojo for configured events such as prompt submission, tool use, permission requests, stop, and session end. The hook command records only the configured event name and current timestamp. It does not parse or persist hook stdin.

WaitDojo never approves, denies, mutates, or rewrites coding-agent actions.

Chess puzzles download only when you ask.

The one practice-content fetch in the product is waitdojo chess download: a single ranged HTTPS request to the public, CC0-licensed Lichess puzzle database. It runs only when you type that command—never on install, launch, play, or a timer—and carries no account, token, or local data. Bundled and cached puzzles need no download. Beta-gated builds also require a valid cached access confirmation to launch offline.

Codebase teachback is unaffected: your repository's questions and evidence never leave your machine.

WaitDojo application analytics keeps aggregate counts, not visitor profiles.

The WaitDojo application increments daily totals for a strict event vocabulary: page viewed, demo viewed or completed, installer requested or copied, selected agent, install section viewed, beta waitlist interest submitted, and invitation claim viewed or completed. The two claim milestones are payload-free and sent without browser credentials; other rows may include only selected agent, coarse platform, and coarse campaign bucket.

At the application layer, the funnel payload does not accept or store a visitor ID, session ID, IP address, user agent, page URL, repository, referrer, prompt, code, or arbitrary properties. WaitDojo application analytics honors Browser Do Not Track. In-page once-only guards reduce duplicate page, demo, and installer-intent events without persistent identifiers.

The hosting provider may separately process standard request data or set necessary security cookies, including __cf_bm, for delivery, security, and abuse prevention. Those systems are outside WaitDojo's application analytics.

The copied installer command receives only the same fixed campaign bucket already used by this page. When Do Not Track is enabled—or JavaScript cannot safely determine a bucket—it receives unknown. The product saves that coarse label locally with installation metadata. In the published v0.2.6 release it is eligible to upload only after the user enables remote backup.

Waitlist email is optional and separate.

The invited-beta waitlist stores only a normalized email address and fixed signup source. It does not store the page, referrer, UTM parameters, prompt data, or repository data. Submitting interest does not grant beta access. Unsubscribe from any invitation or beta email.

Published beta: access checks required, backup optional.

The published v0.2.6 invited beta requires GitHub sign-in and access checks. Supabase backup remains off until you enable it. Backup is a one-way upload of sanitized completed-activity metrics and allowlisted product events, not cross-device progress restoration. Local progress remains authoritative. Turn uploads off with:

Terminalbash
waitdojo config set supabase_mode off

The published v0.2.6 release does not force activity uploads. Its invitation gate does not enable progress backup or change your telemetry settings. You can disable local telemetry and remote backup independently with the commands on this page.

Questions about this contract can be sent to Nishant Bhargava.