session cookie set on example.com is invisible to app.example.com, both on https Cookies

It is the __Host- prefix and it is doing exactly what it is designed to do.

That prefix forbids a Domain attribute by specification. Not "ignores it" - the browser drops the entire Set-Cookie if you include one. So a __Host- cookie is permanently host-only and there is no combination of attributes that will make it visible on a subdomain. Auth.js uses prefixed names in production, which is why this only appears when you deploy.

To share it, override the cookie config: change the name to a __Secure- one and set the domain explicitly.

cookies: {
  sessionToken: {
    name: '__Secure-authjs.session-token',
    options: { domain: '.example.com', sameSite: 'lax', path: '/', secure: true, httpOnly: true }
  }
}

Keep SameSite=Lax. A subdomain is the same site, so Lax is not the thing blocking you here and loosening it buys nothing.

Do it knowing what you are giving up. Once the session cookie is scoped to .example.com, every subdomain can read it - including whatever marketing deploys on blog.example.com next quarter with three analytics scripts on it, and including any subdomain someone can get content onto.

That is a real trade and worth making deliberately rather than because it unblocked a redirect loop on a Friday.

Alternative shape if the blast radius bothers you: keep the session host-only on the auth origin and give app.example.com its own cookie through a short redirect handshake at login. More moving parts, and the cookie a compromised subdomain can steal is scoped to that subdomain only. Worth it above a certain size, overkill below it.

Unrelated but adjacent: in local dev, localhost and 127.0.0.1 are different origins as far as cookies are concerned, and that will independently cost you an hour on some other day. Pick one and put it in the readme.

Set SameSite=None; Secure and it will start working across subdomains.