fix(auth): Auto-recover project-less session after re-auth

[charlesvien]

Problem

After the OAUTH_SCOPE_VERSION bump forced a re-authentication, a transient org/projects fetch failure (a network blip on a fresh re-auth) leaves the user authenticated but with no project selected (currentProjectId = null), and nothing recovers it. That single state silently cascades:

• cloud sends fail with "Authentication required for cloud commands"
• the Cloud workspace mode disappears (the twig-cloud-mode-toggle flag has no posthog project group to evaluate against)
• the billing/usage bar goes blank
• the task list empties

Reported by Gustavo, who got stuck on local/worktree-only after re-auth.

Changes

1. Distinguish transient (network/5xx) org-fetch failures from permanent (4xx) ones, and flag the session orgProjectsIncomplete only for the transient case
2. Add a bounded, deduped refreshOrgProjects() that re-fetches orgs/projects and re-selects the project via the existing pickInitialProjectId
3. Trigger recovery after an incomplete sync and from attemptSessionRecovery (connectivity-online + power-resume handlers)
4. Preserve the last-selected project across a project-less sync so recovery restores the exact project the user had
5. Tests for recover-and-restore on reconnect, recover on resume, and the empty-scoped_organizations no-retry path

Once currentProjectId is restored, the rest cascades back automatically (cloud sends, the cloud-mode flag via the re-set posthog project group, the seat/usage bar, and the task list), so no UI changes are needed.

Related (adjacent angles of the same incident): #2594 (analytics feature-flag race hiding the cloud option) and #2647 (explicit OAuth scopes instead of *).

How did you test this?

• pnpm --filter @posthog/core test — 31 auth tests pass (3 new recovery tests + existing suite, including the existing 4xx no-retry case)
• pnpm --filter @posthog/core typecheck — clean
• biome lint packages/core/src/auth/* — clean

New unit tests fake a transient /api/organizations/{id}/ failure during re-auth and assert the session becomes authenticated-but-project-less, then recovers and restores the previous project on reconnect and on resume; and that an empty scoped_organizations does not trigger a retry loop. No manual app run.

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

[charlesvien]

• fix(analytics): Resolve feature flags before first render #2656
• fix(auth): Auto-recover project-less session after re-auth #2655 👈 (View in Graphite)
• fix(agent): Surface real session-init errors and kill leaked CLIs #2654
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[github-actions]

React Doctor found no issues in the changed files. 🎉

_{Reviewed by React Doctor for commit 210a0ae.}

[stamphog]

Gates denied this PR because it touches auth code (on the deny-list) and is classified as too complex for automated approval. The changes modify session persistence behavior (preserving prior selectedProjectId when null, skipping preference writes when no project is selected) and introduce a new async recovery loop — all in the auth service, which requires human review.

[greptile-apps]

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
packages/core/src/auth/auth.test.ts:873-971
**Reconnect and resume tests could be parameterised**

The "recovers on reconnect" and "recovers on resume" tests share the same arrange-and-assert skeleton — transient failure during login, switch to online, fire the recovery trigger, wait for `currentProjectId`. The only variation is the recovery trigger (`emitStatus(true)` vs `getResumeHandler()()`) and the expected restored project (84 vs 42, which itself follows from whether a prior session is seeded). Per the team's rule on preferring parameterised tests, an `it.each` table over `[{ trigger: emitStatus, expectId: 84, seed: true }, { trigger: getResumeHandler()(), expectId: 42, seed: false }]` would express the shared intent more clearly and make it cheaper to add a third trigger in the future.

### Issue 2 of 2
packages/core/src/auth/auth.test.ts:873-971
**Retry loop inside `doRefreshOrgProjects` has no multi-failure test**

`doRefreshOrgProjects` retries up to `ORG_RECOVERY_MAX_ATTEMPTS` (5) with exponential backoff. The new tests only exercise the first-attempt-succeeds path: connectivity is restored, recovery fires once, and the project is set. There is no test for "2 transient failures then success" within a single recovery window, nor for "all 5 attempts fail and the session stays project-less". Per the team's rule on retry-logic coverage, at least one test should drive multiple failures through the loop before letting the stub succeed, verifying that the session remains incomplete during retries and is committed only on the successful pass.

_{Reviews (1): Last reviewed commit: "auto-recover org projects after failed a..." | Re-trigger Greptile}