Repository navigation
feat(cli): simplify domain add/status output for HTTP-DCV - #214
Conversation
Custom-domain certificate validation now uses HTTP-DCV at Cloudflare's edge, so there are no user-facing `_acme-challenge` SSL-validation records and renewals are fully automatic. - `domain add` now prints two sections — traffic CNAME + ownership TXT — and drops the "TXT (SSL validation)" section plus its deadline-miss fallback hint (both dead/misleading under HTTP-DCV). Summary updated to "Add both records above". - `domain status` only surfaces the ownership TXT while it is still outstanding; the SSL-DCV record block is removed (issuance and renewals never surface user records). `computeRollup` is unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
❌ Deploy Preview for staging-void-cloud failed.
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f477b73639
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
The `void domain add` summary hardcoded "Add both records above", but the CNAME and ownership-TXT sections are each conditional. When the API returns fewer than two records the wording was misleading (and in the zero-record case pointed at records that weren't displayed). Build the record sections first and derive the summary from them: singular "the record above" for one, plural "the records above" for two, and render nothing when there are none. Addresses inline review on #214. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 22eb5f4356
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…ting `void domain status` only printed a DNS record while the ownership TXT was outstanding, so once ownership verified but HTTP-DCV was still pending it showed "issuing cert... No action needed" with no CNAME — even though a missing/misconfigured traffic CNAME is exactly what blocks HTTP-DCV (the hostname must proxy through Cloudflare). Now surface the CNAME whenever `ssl_status !== 'active'` (suppressed once live), alongside the ownership TXT, with a count-aware title; and soften the issuing_cert diagnostic to point at the CNAME. Uses the `cname_target` the status endpoint now returns; degrades gracefully (renders nothing) against an older API that omits it. Addresses inline review on #214. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
`void domain add` now prints the traffic CNAME + non-rotating `_cf-custom-hostname` ownership TXT (no `_acme-challenge`, auto-renew); `void domain status` surfaces both records while the cert is validating and notes that activation is automatic via the reconcile cron. Adds a wildcard-not-supported note. Documentation-only. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit bdeff52. Configure here.
The `issuing_cert` rollup diagnostic cited "confirm the traffic CNAME below," but the CNAME block only renders when `status.cname_target` is set — so a target-less status response (e.g. an older API during the deploy window) showed the hint with no CNAME block. Gate the hint on `status.cname_target` so it matches exactly when the block renders (`ssl_status !== 'active'` always holds in this branch), and add unit tests for both branches. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9976da50c2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
The custom-domain CNAME target is API-provided and varies by environment (e.g. cname.staging.void.app on staging). The reference now points users at the target shown in `void domain add` output instead of a fixed `cname.void.app`, matching what domainAdd() actually prints. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

What
Custom-domain certificate validation is moving from TXT-DCV to HTTP-DCV (validated at Cloudflare's edge once the hostname proxies through it). Under HTTP-DCV there are no user-facing
_acme-challengeSSL-validation records and renewals are fully automatic, so the CLI's domain output can be simplified.This is the framework half of the migration. The platform half (API activation gate + create-flow + janitor) is a separate PR in
voidzero-dev/void-platformthat bumps the submodule pointer to this commit.Changes
domain addnow prints exactly two sections — traffic CNAME + ownership TXT — and drops the "TXT (SSL validation)" section plus its deadline-miss fallback hint (both dead/misleading under HTTP-DCV). Summary updated to "Add both records above".domain statusonly surfaces the ownership TXT while it is still outstanding; the SSL-DCV record block is removed (issuance and renewals never surface user records).computeRollupstate machine is unchanged.Why
Adding a custom domain previously forced 3+ DNS records (CNAME +
_cf-custom-hostnameownership TXT + 1–2 rotating_acme-challengeTXT). The_acme-challengeset rotates on every ~90-day renewal and silently drops domains back to pending/404 when nobody re-publishes it (hit live onviteplus.dev). HTTP-DCV collapses the set to 1 CNAME + 1 non-rotating ownership TXT.Tests
packages/void/test/unit/domain-command.test.ts— 39 passing (two-section reveal assertions; SSL-record/SSL-pending-block assertions removed).🤖 Generated with Claude Code
Note
Low Risk
CLI and documentation-only UX changes for custom domains; no auth or deploy logic touched, though users on older TXT-DCV expectations may need the paired platform PR.
Overview
Aligns
void domain addandvoid domain statuswith HTTP-DCV: users only configure a traffic CNAME and a_cf-custom-hostnameownership TXT. All_acme-challenge/ TXT (SSL validation) output and the “records will appear in status shortly” fallback are removed.domain statusnow shows pending DNS as CNAME (whilessl_statusis not active) + ownership TXT (while present), with singular/plural note titles andissuing_certdiagnostics that mention the CNAME only when acname_targetis actually printed. CLI reference docs are updated (HTTP validation, no wildcards, automatic activation / background reconcile).Unit tests in
domain-command.test.tsare rewritten for the two-record model and the new status pending-block behavior.Reviewed by Cursor Bugbot for commit 206a073. Bugbot is set up for automated code reviews on this repo. Configure here.