fix(desktop): keep polling after an update is staged

[charlesvien]

Port of PostHog/code#3860 into the monorepo (products/desktop/), remade here because desktop now lives in posthog.

Problem

Once an update downloads, the app stops its hourly update poll and ignores every later update event. Users update, restart and immediately get another "update available" prompt because a newer release shipped while the staged one sat waiting. Fixes the update chain reaction reported on Discord and Slack.

Changes

• Everything is gated behind the posthog-desktop-staged-updates feature flag, off by default. The renderer syncs the flag to the main process once posthog flags load. Flag off keeps the legacy flow. Flag on after staging restarts the poll.
• UpdatesService keeps the hourly poll running in the available and ready states. Periodic checks run silently with no UI flicker.
• A background check that finds a strictly newer version than the staged one downloads and re-stages it (auto-download on) or surfaces it as available (off). Same or older feed versions never replace a staged build, so a manifest rollback cannot downgrade an already staged client.
• Library-level autoUpdater.autoDownload is now permanently false and IUpdater.setAutoDownload is removed. The service is the sole caller of download() and downloads are serialized (queueDownload) because electron-updater silently no-ops a downloadUpdate() while a previous one is still in flight.
• Feed rollbacks below the running version and re-download errors fall back to the staged build, which still installs on quit.
• deriveUpdateUiStatus clears the stale staged version on the newly reachable transitions out of ready.
• desktop-update-e2e.yml gains the chained re-stage leg (stage 2.0.0, bump feed to 3.0.0, re-stage, restart lands on 3.0.0), re-derived from the source workflow per the MIGRATION.md transform rules rather than patched.

Port notes: apps/code/snapshots.yml from the original PR is intentionally skipped. It is the PostHog/code VR baseline and desktop storybook CI was removed from the monorepo (see MIGRATION.md).

How did you test this code?

Automated only, run from products/desktop/:

• pnpm typecheck: 24/24 packages pass.
• pnpm --filter @posthog/core test: 2880 tests pass, including the new suites for background polling, re-staging, the downgrade guard, download serialization, rollback and error fallbacks, plus flag-off coverage of the legacy flow.
• pnpm --filter @posthog/shared test: 769 tests pass.
• pnpm exec biome lint packages/core: clean.
• actionlint and hogli lint:workflows: clean.

The chained e2e leg passed on the source repo's Code Update E2E (macOS) workflow (run 30349976739, chain proof PASS). Here it runs in the nightly desktop-update-e2e.yml, which I did not trigger.

Automatic notifications

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

Docs update

N/A

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Claude Code ported the open PR PostHog/code#3860 onto products/desktop/ at Charles's direction. The tree diff applied cleanly via 3-way apply against the pinned import SHA. Decisions: skipped the snapshots.yml VR baseline (storybook CI removed post-import, per MIGRATION.md) and re-derived the desktop-update-e2e.yml changes using the MIGRATION.md transform rules instead of hand-merging the source diff.

[trunk-io]

😎 Merged successfully - details.

[trunk-io]

   

View Full Report ↗︎ ⋅ Docs

[greptile-apps]

Prompt To Fix All With AI

### Issue 1
products/desktop/apps/code/src/renderer/platform-adapters/updates.ts:137-146
**Failed flag sync blocks retries**

When the first `setStagedUpdates` mutation fails, `lastSyncedStagedUpdates` still records the value as synchronized, so later callbacks with the same flag value skip retrying and the main process keeps staged-update polling disabled for the session.

```suggestion
function syncStagedUpdates(): void {
  const enabled = posthogFeatureFlags.isEnabled(STAGED_UPDATES_FLAG);
  if (enabled === lastSyncedStagedUpdates) return;
  lastSyncedStagedUpdates = enabled;
  void hostTrpcClient.updates.setStagedUpdates
    .mutate({ enabled })
    .catch((error: unknown) => {
      if (lastSyncedStagedUpdates === enabled) {
        lastSyncedStagedUpdates = null;
      }
      log.error("Failed to sync staged-updates flag", { error });
    });
}
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "keep polling for updates after staging" | Re-trigger Greptile}

[veria-ai]

PR overview

All previously flagged issues have been addressed. No open security concerns remain on this pull request.

Security review

No open security issues remain on this pull request.

Fixed/addressed: 1 · PR risk: 0/10

[stamphog]

Note

🤖 stamphog reviewed 289c875e6677e46e60330854fc6b492c6bbb8422 — verdict: REFUSED

Gates denied this PR (CI workflow change hit the infra_cicd deny-list, and size/scope classify it T2-never); it also touches security-relevant auto-update/rollback logic, so it needs human sign-off despite bot review coverage.

• 👍 on the PR from greptile-apps[bot], hex-security-app[bot].
• Deny-list match: .github/workflows/desktop-update-e2e.yml was modified — CI/infra territory requiring human review
• Classified T2-never given size (1461 lines/15 files, two areas: CI + desktop update logic)
• Update/rollback logic is security-sensitive; greptile flagged a P1 retry-blocking bug and veria-ai flagged a feed-rollback-bypass risk — both marked resolved but a human should confirm the actual fix rather than relying on bot self-report

Gate mechanics and policy version

Gate		Result
prerequisites	✓	all clear
deny-list	✗	matches: infra_cicd
size	✓	325L, 10F substantive, 1461L/15F incl. docs/generated/snapshots — within ceiling
tier	✗	classified as T2-never: T2-never (1461L, 15F, two-areas, fix)
stamphog 2.0.0b4		.stamphog/policy.yml @ 5d5ff6b · reviewed head 289c875

[charlesvien]

/trunk merge

[deployment-status-posthog]

Deploy status

Environment	Status	Deployed At	Workflow
dev	✅ Deployed	2026-08-04 04:35 UTC	Run
prod-us	✅ Deployed	2026-08-04 04:49 UTC	Run
prod-eu	✅ Deployed	2026-08-04 04:47 UTC	Run