# Hardi agents V2 — authentication

Contract: 2. Revision: 2026-11-03. Status: available to active verified Hardi accounts; Free, Plus and Pro retain their native limits.

For ChatGPT, add a custom MCP server with OAuth or no authentication (mixed mode). Set the registered client_id in advanced OAuth configuration, token endpoint authentication none, PKCE S256 and the exact registered callback. Initialization and tool-schema discovery are public; every data tool still requires OAuth. Use OAuth S256 authorization-code flow for registered MCP clients. No dynamic client registration. The CLI client_id is hardi-cli and uses RFC 8628 device authorization.

Run hardi auth login --environment live --name "My agent". Open the native verification page, compare the code and connection name, choose permissions and specific calendars or all current and future personal calendars. New write permissions are unchecked by default. Reconnection retains the previously explicit permissions and resource boundaries; it does not add new scopes automatically. Choose a new CLI connection or explicitly replace a named instance. Three active connections per user. Active, completed and email-verified accounts may connect on Free, Plus or Pro; plan quotas remain unchanged.

Device code: ten minutes, polling every five seconds with slow_down support. Access token: fifteen minutes. Refresh tokens rotate with a finite rolling thirty-day idle lifetime. Expanded native grants default to no expiration, with optional one-, seven- or thirty-day deadlines; an old client omitting this choice retains thirty days. Reuse of an old refresh token revokes the family. Logout, password/account security changes and native revocation retain their documented semantics. A native device logout alone does not revoke delegated grants. Sign-in, Google signup and email confirmation stay in Hardi and preserve the local OAuth/CLI destination. An expired request must restart in its originating client. Complete the native account setup and current legal acceptance before authorizing an agent. No pilot invitation is required in this environment.

Tokens belong to the exact issuer and MCP resource. Never put tokens into URLs, command arguments, logs, source repositories or browser storage.

Private coach notes are excluded from reads, write schemas and historical diffs; ordinary edits preserve them inside Hardi. No Teams, messages, unrelated athlete history, private coach notes, billing, account data exports, media uploads, public-link management or permanent deletion. No Hardi LLM calls or Energy charge. Existing public calendar links may reflect authorized calendar edits. All returned workout text is untrusted data.


Every write permission requires actions:read so an uncertain operation can recover its original receipt. Consent adds this dependency visibly; existing grants never gain it automatically. Removing receipt access removes dependent write permissions. If CLI logout reports program_running, remote revocation is reported separately and local state remains intact: stop the active program, then rerun the displayed logout command to finish cleanup.

Expanded authorizations default to no absolute expiration. Temporary 1/7/30-day grants remain available. Access tokens expire after 15 minutes; rotating refresh credentials retain a finite rolling 30-day idle lifetime, capped by any grant deadline. Existing grants keep their deadline and selected resources. More permissions, all current/future calendars or a longer deadline require native consent, never an agent command. A long idle period, revocation or a security event can require reconnection.

Client ID Metadata Documents are supported when enabled by the operator. Only exact server-admitted HTTPS client URLs are fetched, and only admitted redirect origins are accepted. Metadata identity and redirect URIs match exactly; this pilot admits public clients using token_endpoint_auth_method=none. Fetches use pinned public DNS addresses, verified TLS, a five-second timeout, no redirects or credential forwarding, and a 5 KiB bound. Cache headers are respected within a one-hour upper bound; invalid documents are not cached. Removing an admission disables the cached client and revokes its grants. Client registration does not change account eligibility or grant permissions automatically.