id_token lacks email claim for non-provider sessions, creating duplicate planner members

[mroderick]

Users signing in through the planner's codebar login could be dropped into a brand-new, empty account — no subscriptions, no roles — because the planner received an id_token without an email claim.

Timeline (2026-10-02)

• 10:01 UTC — auth release v64 deployed better-auth 1.6.27 → 1.7.5
• 13:18 UTC — first affected sign-in: planner created duplicate member 31450
• 15:06 UTC — second affected sign-in: planner created duplicate member 31452; reported by the member's organiser
• 16:34 UTC — mitigated by rolling back to the v63 code (release v65)

Mechanism

Two independent behaviours combine:

1. better-auth 1.7 stopped including user-record claims (email, name) in the id_token for sessions not created through a social provider (magic-link sessions). The claims hook receives the full user record and the correct scopes, but the claims are absent from the signed token.
2. The planner resolves members by the id_token's email claim and falls back to sub when the claim is absent (email = payload['email'] || payload['sub'] in lib/omniauth/strategies/codebar.rb). With the claim missing, the fallback creates a member whose email and name are the better-auth user id — an opaque 32-character id. Nothing matches the real account, so member:duplicates:detect finds nothing.

Fix

• fix: always emit email and name claims in the planner id_token #83 — customIdTokenClaims always emits email and name from the user record for every session type; better-auth and @better-auth/oauth-provider bumped to 1.7.7; regression tests cover both the magic-link and linked-GitHub paths

Follow-ups

• Planner: harden the codebar strategy against the sub fallback (fail loudly or fetch the userinfo endpoint instead)
• Cleanup: identify any affected users and fix them (garbage members 31450 and 31452 included) — Cleanup: identify and fix users affected by the id_token email-claim regression planner#2984