fix(plugin-auth): a verification-email resend from a visitor who is not signed in answers the same whatever the send does - #30144

📓 Docs Drift Check

15 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin b09fc767ad4a6cd8af1022e8a1044cd703f876ce && git checkout b09fc767ad4a6cd8af1022e8a1044cd703f876ce
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 55337f4ce35dbe62434b23517547a0b5052b936c 4200bbebc7fa86bc43e9e93422cbfaeb134c34d9 && git checkout -B drift-repro 55337f4ce35dbe62434b23517547a0b5052b936c && git merge --no-ff 4200bbebc7fa86bc43e9e93422cbfaeb134c34d9

node scripts/docs-audit/affected-docs.mjs --json 55337f4ce35dbe62434b23517547a0b5052b936c

security#1 · os-justin · session_01QSeKYn5CmmdShCJifm6WYj

Contract-review-claim: session_01QSeKYn5CmmdShCJifm6WYj · head 4200bbe · 2026-11-04T16:32Z

security#1 · os-justin · session_01QSeKYn5CmmdShCJifm6WYj

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 4200bbebc7fa86bc43e9e93422cbfaeb134c34d9
Local-runs: none
Scope: packages/plugins/plugin-auth/src/visitor-verification-resend.ts, packages/plugins/plugin-auth/src/auth-manager-auth-instance.ts, packages/plugins/plugin-auth/src/auth-manager-before-hook.ts, packages/plugins/plugin-auth/src/signup-existing-address-success-shape.test.ts, packages/plugins/plugin-auth/src/verification-email-failure-propagation.test.ts + packages/plugins/plugin-auth/src/run-after-response.ts, packages/plugins/plugin-auth/src/auth-manager-actor-guards.ts (resolveActor), packages/plugins/plugin-auth/src/auth-manager.ts (isEmailDeliveryLive), packages/plugins/plugin-auth/src/send-verification-email.ts, packages/plugins/plugin-auth/src/auth-plugin.ts (the shadowing resend route), better-auth 1.7.12 dist/api/dispatch.mjs, dist/api/routes/session.mjs, dist/api/routes/email-verification.mjs, dist/plugins/bearer/index.mjs, ui/apps/console/src/pages/auth/VerifyEmailPromptPage.tsx, scripts/check-empty-changeset.mjs, .github/workflows/pr-automation.yml

Inputs: the PR body, its file list, the net diff against the merge base a52761fdd7, the check-runs on the head, and the ruling (maintainer, 2026-11-04, option G). The committed tree touches no published schema and no governed path; the PR body and both changesets declare Clause-②: no with no arm, so the tree itself decides no review face. This record is the at-tier review the seat ordered for a security-channel fix, and the scope above is every path of the diff outside the prose faces plus the code those hunks cite.

Check-runs on the head: every check is completed; none is still running. All are green except Check Changeset (two runs, both failure). Its only annotation is the foreign-changeset refusal on .changeset/sign-up-mail-after-response.md, the DELIBERATE CORRECTION class the gate's own header names. Red by design: the gate's header says the check stays red either way; the workflow that runs it (pr-automation.yml) triggers on pull_request only, never merge_group; the check is not a required context. The third red-by-design condition, a PR comment naming the gate and the cause, is still owed: the body names it, a comment does not yet.

① Derived judgments

1. The rule under a live transport holds. sendAfterResponseOnSignUpAndVisitorResend hands the visitor's resend to sendAfterResponseOnPublicDoor, whose deferral is keyed on the Request the call carries, so the visitor's send runs after the response and its failure reaches logAfterResponseSendFailure only. Read in better-auth's resend route: for a caller it finds no session for, an address with no account or an already-confirmed one never reaches the send callback (a token is minted locally), and the remaining address reaches it; with the send deferred, every one of the three answers 200 { status: true } behind the route's own floor. Correct, and ablation leg 1 (two timeouts) pins exactly this.
2. The rule under a non-live transport holds. refuseVisitorResendWithoutLiveTransport runs in globalBeforeHook ahead of the endpoint, is keyed on the endpoint's declared path and the presence of a Request, reads isEmailDeliveryLive once, and refuses every caller resolveActor finds no user for with one coded body, 400 EMAIL_SERVICE_REQUIRED, before any address is read. Correct. The code is the one plugin-auth already answers on /change-email and in the identity import for the same deployment condition; it is typed against the ADR-0112 ledger (RegisteredErrorCode), so no ledger change.
3. The signed-in resend stays honest. A caller resolveActor resolves passes the before-hook; inside the endpoint the route resolves the session and records it on the endpoint context, so isVisitorResendInEndpointContext reads a session and the callback is awaited as before. ⑦'s renamed case and ⑧'s cookie-and-bearer case pin it. Correct.
4. The discriminator: can the two readers disagree in a way that splits answers by address? No. Measured in better-auth 1.7.12: the bearer plugin's before-hook returns its cookie as a context patch, and dispatchAuthEndpoint merges every before-hook's patch into the request headers only after runBeforeHooks has returned, so a bearer caller reads as no session to getSessionFromCtx inside our before-hook; resolveActor reads the bearer header itself (unsigned token against the session store) and is the right reader there. Ablation leg 3 pins it. The two readers can still disagree in one direction, a credential the store knows but whose signature the endpoint does not accept: the before-hook then passes and the endpoint reads a visitor, and the callback decides how the send runs, so every address still gets the same 200. In the other direction (before-hook reads no caller, endpoint reads a session) the refusal is address-independent by construction. Neither direction produces an answer that depends on the address. The cached context.session the before-hook's read leaves behind is null for a visitor, which the endpoint's reader treats as unread and re-reads, so no stale reading crosses from the hook into the endpoint.
5. A server-side auth.api call with no Request is neither deferred nor refused — right. The ruling is about the visitor on the public door; a call with no Request is the deployment's own code, and the previous changeset already states it awaits its send. The one in-repo relay, the shadowing POST …/send-verification-email route in auth-plugin.ts (runResendVerificationEmail), re-dispatches through handleRequest with a real Request carrying the caller's cookie and authorization headers, so a visitor through that door meets both halves of the rule; a visitor with an empty body is refused there before any re-dispatch (email is required). No door bypasses the rule.
6. Clause-②: no (no arm) is true, and the plain no is the right declaration. AGENTS.md Post-Task Checklist step 3 is the rule text: "Clause-②: yes|no plus at most one arm from the closed pair (widening)/(narrowing) ((narrowing) is BREAKING, no (widening) malformed)". The reader's header (scripts/pm/clause2-line.mjs, the authority on detail) states the question the value answers, 「本卡放宽接受集或扩大公开面吗」, and the arm's trigger: "A diff that NARROWS a published accept set answers it no truthfully — and a narrowing is a breaking change." The accept set of POST /send-verification-email is unchanged: the same body, the same callers, no export, schema or ledger entry moves (the new module is not re-exported; index.ts does not name it). What moves is the answer under a deployment condition the platform already names a refusal, through the one reader of that fact (isEmailDeliveryLive, which already decides the sign-up answer and the invite outcome, and which plugin-email answers false for its log transport in every environment). The template's own test for the narrowing face is whether the change "takes a declared capability away at the consumer, or makes the spec's own refusal real": a visitor's 200 on a log transport was a send to a log the visitor cannot read, and on an address with no account it was no send at all; the platform's refusal for that condition becomes real on one more door. Not a narrowing of a published accept set, so no !, no (narrowing) arm, no BREAKING banner, no ADR-0087 marker, and no full dogfood battery owed (os-dev: the battery runs only on a ! title or a (narrowing) arm). The judgment is close enough to record its one user-visible edge in ③.
7. The pending changeset correction is right, and the edit stands. .changeset/sign-up-mail-after-response.md line 12 listed the resend as unchanged; this PR keeps that true only for a signed-in caller, so the sentence now says so. Restoring the line from the merge base would republish a sentence this PR makes false, which is the one thing the gate's header says not to do. The new changeset visitor-verification-resend.md is patch on @objectstack/plugin-auth with both declaration lines at line start; its prose matches the diff.
8. §6 holds. Title, body, both changesets and every test name state the rule (the same answer whatever the send does, whatever the address; one coded refusal while no transport is live). No advisory id, no attack wording, no mechanism narration beyond the rule; the one "probe" in the scan is pre-existing test-file prose on an unchanged line.

② Semver level

patch on @objectstack/plugin-auth (released 18.3.0): Metadata-protocol: none is true (nothing an author writes changes), Clause-②: no with no arm is true per ① item 6, and a bug fix in a released package takes patch. The PR body and changeset lines parse at line start (the PR-body guards are green). Consistent.

③ Boundary flags

• Dev open question 1, the verify screens branching on the code: answered, not owed here. VerifyEmailPromptPage already shows the server's message, and the refusal's message names the capability and the fix (Settings → Mail); the resend's 200 while a transport is live reads as sent, as the ruling orders. A code-keyed string in the console is a ui/ follow-up at the seat's discretion, not a must-fix on this PR.
• Dev open question 2, who confirms the changeset correction: the maintainer, in writing on this PR — escalated. The gate's header calls it "the existing human path" and says staying red "puts the decision in front of a person"; the workflow step says the approver merges over the red. No seat confirms it. Until that written confirmation, the PR waits; the red is by design and blocks no required context.
• Red-by-design condition still owed by the seat: a PR comment naming Check Changeset and the DELIBERATE CORRECTION cause (SKILL.md: 源码自述、不跑 merge_group、PR 评论记明门与因). The first two hold on the tree and the workflow; the third needs the comment.
• User-visible edge of the ruling, for the maintainer's awareness, not a defect: the dev-default log transport is not live, so on a dev deployment a visitor's resend now reads the Settings → Mail refusal instead of writing the link to the log. That is what option G orders; it changes the dev loop for a visitor who has lost the sign-up log line.
• Minor, not a must-fix: while no transport is live, a signed-in caller whose session read throws in the before-hook is refused with the mail-configuration code rather than a read-fault status; the fallback is deliberate (a read that fails counts as no caller) and the condition is doubly degraded.
• The author is objectstack-fleet[bot] (relay); no out-of-relay login to name.

④ Design judgment

• visitor-verification-resend.ts against the ruling and the code it cites: the rule is stated once, the two readers are placed where each can answer (the before-hook asks the actor reader every other before-hook gate uses; the callback asks the session the endpoint recorded), and the module's own fallback statement (the endpoint's reading decides how the send runs) is what makes the answer address-independent under any disagreement. Holds.
• auth-manager-auth-instance.ts: the rename widens the one wrapper from one path to two, keeping the awaited default for every other call; the comments scope the "throw so the resend is honest" rationale to the signed-in caller. Holds.
• auth-manager-before-hook.ts: one call, placed before the lockout gate, with isEmailDeliveryLive added to the host Pick alongside the existing members. Holds.
• Tests: ⑧ asks its three addresses concurrently against a deferred send and reads every answer before releasing it, which is the only honest way to pin "answered before the send settles"; the non-live battery covers the three ways a transport is not live; the signed-in case covers cookie and bearer, which is the exact seam the discriminator has. The scenario the PR is accepted against is covered.

Implemented-by: claude/sec-hardening-w
Reviewed-by: session_01QSeKYn5CmmdShCJifm6WYj

VERDICT: PASS

security#1 · os-justin · session_01QSeKYn5CmmdShCJifm6WYj

Red by design · head 4200bbebc7fa86bc43e9e93422cbfaeb134c34d9 · 2026-11-04T17:12Z

Gate: Check Changeset (scripts/check-empty-changeset.mjs).

Cause: this PR edits a pending changeset that it did not create: line 12 of .changeset/sign-up-mail-after-response.md, from PR #29975. The edit scopes the resend sentence to the signed-in caller, because this PR makes the unscoped sentence false. The gate classes that as a DELIBERATE CORRECTION and stays red until the correction is confirmed in writing on the PR. Its header calls that "the existing human path". The contract review (comment 6636939836) found the edit right: restoring the line would publish a false sentence.

Why the red does not block CI: pr-automation.yml runs on pull_request only, never on merge_group, and this check is not a required context.

Owed: the maintainer's written confirmation on this PR. The seat will not land the PR before it is posted.

security#1 · os-justin · session_01QSeKYn5CmmdShCJifm6WYj

Changeset correction confirmed by the maintainer, 2026-11-05T00:47Z. The confirmation was given in session session_01QSeKYn5CmmdShCJifm6WYj (seat security#1); verbatim:

changeset 改写确认 #30144、#30165 同意

This is the written confirmation that scripts/check-empty-changeset.mjs names as the human path for its DELIBERATE CORRECTION class. The pending changeset edits on this PR stand as they are. Check Changeset stays red by its own design, and the merge goes over it: the check is not a required context and does not run on merge_group.

security#1 · os-justin · session_01QSeKYn5CmmdShCJifm6WYj

席位核对

ACCEPT · head 4200bbebc7fa86bc43e9e93422cbfaeb134c34d9 · 2026-11-05T00:49Z

• Contract review: records 6636939836. The latest record on this head is Served-tier: CONTRACT_REVIEW_TIER, VERDICT PASS, no must-fix.
• Changeset correction: confirmed in writing by the maintainer on this PR (the comment above, quoted verbatim).
• Check-runs at this head (latest per name): 1 failure, 15 skipped, 32 success.
  • The only red check is Check Changeset. It is red by design (the DELIBERATE CORRECTION class); the source says so, it does not run on merge_group, and the cause is recorded on this PR. It is not a required context.
  • Every other check is green.
• Landing: ready, then auto-merge.