[pasqualtroncone]

What

Removing the email provider now turns the sign-in links (magicLink) off along with the email confirmation requirement. The god authentication page saves again after the provider is removed, and a magic-link request is refused instead of being answered as sent.

Why

Closes #665

setEmailSettings cleared only requireEmailVerification when the provider was removed, so a magic link turned on before stayed stored as on:

• The god form sends every setting on each save, and PUT /god/auth-settings refuses magicLink: true without a provider, so every save of the page answered "Configure an email provider first". The switch is disabled without a provider, so it could not be turned off either.
• The magic-link sender reads only the stored setting. /auth-config hides the link from the sign-in page, but a direct POST /api/auth/sign-in/magic-link was answered as sent while the mail was dropped.

packages/auth/AGENTS.md already states the rule for the confirmation requirement: it never outlives the mail provider, so the stored setting is all its readers check. The sign-in links now follow it, and the paragraph says so. Turning the provider on again leaves both off until they are turned on, as the requirement already does.

An instance already in this state is repaired by saving the email settings once.

How to test

1. In god mode, set up the email provider under Integrations, turn Sign-in links on under Authentication and save.
2. Turn the email provider off and save: under Authentication, Sign-in links is off.
3. Change the registration mode and save: it saves.

Tests, in god-email-verification.test.ts:

• turning the magic link on without a provider answers 400 with "Configure an email provider first". No test covered this refusal before.
• removing the provider of a magic link stores it off, a magic-link request answers 403, and the settings the god form sends back save with 200. It fails without the change.

What it covers in each form of the app:

• Sign-in methods: the magic link and the email confirmation requirement, the two settings that need a provider. The other settings are not checked against the provider.
• Interfaces: the god pages and the api routes they call; MCP and the bot do not change auth or email settings. The web already refetches the auth settings after an email save; its comment there now says that a provider turned off clears them.
• Languages: no text changes.
• Deployment: no environment variable, compose file or Helm value changes.

Full battery on this branch: api 2479, bot 4, worker 205, web 429 tests pass.

Checklist

• bun run typecheck passes
• bun run lint and bun run format:check pass
• Tests added or updated for the changed behaviour
• Database schema changed: migration generated with bun run db:generate and committed (not applicable)
• New environment variables documented in .env.example (not applicable)
• Docs updated (README.md or the relevant AGENTS.md): packages/auth/AGENTS.md

Screenshots

Not applicable: no screen changes.

A note on how this was made

This change was vibe coded. I'm sharing it because I have been using it
extensively in my own self-hosted deployment, and it may be useful to others too.

[grootbro]

Reviewed all four changed files at 9236a7e. Clearing both mail-dependent flags when the last provider is removed matches the existing verification-setting invariant; the auth-settings refetch keeps the god form in sync.

I checked the exact-head CI run 39731429095 and its test log: both new magic-link-without-a-provider regressions pass, including the refused link request and the subsequent full auth-settings save. Build, quality checks and CodeQL are green. No findings from this source review. I did not run a separate local or live-instance test.