fix: always emit email and name claims in the planner id_token

[mroderick]

Users signing in through the auth app could be dropped into the planner's new-member flow, losing their subscriptions and roles, because the planner received an id_token without an email claim and fell back to sub (the better-auth user id). This fix makes every id_token carry the user's email and name, and bumps better-auth to 1.7.7.

• customIdTokenClaims now always emits email and name from the user record, for every session type (previously it only returned github_id)
• better-auth and @better-auth/oauth-provider bumped 1.7.5 → 1.7.7
• Test suite aligned with production config and now covers the regression

Background and mechanism

The planner's codebar OmniAuth strategy resolves the member by the id_token's email claim, falling back to sub when the claim is absent:

email = payload['email'] || payload['sub']

better-auth 1.7 stopped including user-record claims (email, name) in the id_token for sessions not created through a social provider. A user who signed in by magic link therefore got a planner member whose email and name were the better-auth user id — an empty account with no subscriptions or roles. Two such duplicate members were created in production on 2026-10-02; the incident was mitigated by rolling back the auth deploy.

The missing user-record claims affect any session without provider data; the explicit claims in customIdTokenClaims are spread after the library's default claims, so they are always present.

A separate integration test reproduces the scenario: magic-link session → authorize → token exchange → id_token claims. Under 1.7.5/1.7.7 without this change, the email and name claims are absent; with it, they match the user record.

Review notes

Focus first on the claims semantics: every id_token now carries the better-auth user-record email. For users whose GitHub primary email differs from their stored planner email, the planner now matches (or keys a new member) on the user-record email, with the github_id claim still available to resolve returning members. Check that interplay for accounts where the two emails diverge.

Also worth a look: the lockfile diff is now minimal. Only the better-auth family moves 1.7.5 to 1.7.7 (plus one @types/node patch float from peer materialisation), and better-auth is pinned exactly to 1.7.7 to match the @better-auth/oauth-provider pin. Review fixes landed on top: the claims builder is shared between src/auth.js and the test helper, the linked-GitHub test asserts email and name, and the oauth-flow test registers teardown.

Deliberately not done here: hardening the planner's || payload['sub'] fallback (separate planner change), and setting the client's scopes column in the seed (authorize falls back to the plugin's allowed scopes).

[mroderick]

Tracked in #87.

[till]

Would this be fixed if the planner requested email explicitly?

[mroderick]

Would this be fixed if the planner requested email explicitly?

No. Me and my synthetic research assistant checked the 1.7.7 source to be sure