Switching accounts wipes the browser cache

The moment the account you're viewing changes, everything the app cached in the browser is deleted — everything except your login and your light/dark preference.

What it is

A deny-all purge that runs before any data view can read from browser storage. It compares a URL-derived hint for the account currently on screen against a stored marker; if they differ, it deletes every app key in local storage rather than trying to enumerate which ones are tenant-specific.

Also called: cached data from another account · stale data after switching · localStorage purge

See it
Switching accounts wipes the browser cache
CustomerBuildingAmountStatus
Ivy Brubaker40×64 Shop$3,100Sent
Delia YoderBarndominium$6,900Paid
Delia YoderHobby Shop$14,120Sent
Ronan PetschHobby Shop$7,090Draft
Marlin HooverRiding Arena$14,500Open
A switch animation where the board briefly empties and repopulates with the new account's cards. Triggered from src/lib/AppContext.tsx via src/lib/tenantCache.ts. Sample data — no customer information appears here.
How it works
  1. 1getTenantHint() derives a stable identifier from the URL alone — the impersonation parameter if present, otherwise the subdomain label.
  2. 2enforceTenantCacheBoundary() compares it with the stored marker and returns immediately if unchanged.
  3. 3On a change it deletes every local-storage key except the auth provider's keys, its own marker, and the device theme preference.
  4. 4It runs from a lazy state initialiser at the top of the root provider, so it executes during that render — ahead of any child view's render or effects.
  5. 5The cost is a single re-fetch from the account-scoped API, which is the correct source.
Why we built it

The header explains why it is scorched-earth rather than surgical: app caches use keys that are 'NOT scoped by sub-account', local storage is per-origin, and in production every account shares one domain — so 'without a boundary the previous sub-account's cached data would bleed into the next one's view — a privacy breach.' Deny-all was chosen deliberately 'so it can NEVER miss a leaking key.' The theme exception is a bug fix in its own right (L2B-85RPA3): purging the theme key 'made light/dark silently revert to the OS preference on every platform↔tenant switch, which read as the app randomly flipping themes on refresh.'

The problem
  • Cached lists from a previously viewed account rendering under a new account's name.
  • An allowlist approach that would eventually miss a newly added cache key.
  • A device preference being destroyed by a data-privacy purge.
Sound familiar?
What you get
No previously viewed account's data survives a switch.
You stay logged in and keep your theme through the purge.
Views repopulate from the account-scoped API, which is the authoritative copy.

See it on your own jobs

Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.

or keep browsing features →