The sidebar renders from the URL, but the acting account comes from a server-maintained cookie and every API response is scoped to that. When they disagree — a switch whose cookie hasn't landed, a hash navigation that never re-ran middleware, a tab restored from an older session — the client stops trusting the URL, purges its cache and reloads once so middleware can settle the cookie and the page can repaint honestly.
Also called: wrong company name in sidebar · editing the wrong account · acting org mismatch
- 1The client compares the org id the server reported with the org the URL asked for and with the org this tab last saw.
- 2A mismatch or a switch triggers one purge-and-reload, guarded by a per-page-life flag.
- 3If a reload has already been tried, it logs a loud console error naming both accounts instead of looping.
- 4The stored marker is updated on every pass so a later switch is detected.
The header for this section, written under bug code L2B-NR9NJU, is careful about what kind of problem this is: 'That is not a leak: each response is correctly scoped to exactly one org, and only an owner or staff with tenants.impersonate can be in this state at all. It is worse in a quieter way — the operator edits, deletes or messages the wrong customer's records believing they are somewhere else.' The loop guard is equally deliberate: 'a genuinely stuck mismatch surfaces as a console error rather than an infinite refresh', and the error text tells the reader outright, 'Do not trust the tenant name on screen.'
- An operator working inside multiple accounts could edit the wrong one while the header showed a different name.
- A cookie that hadn't landed yet made the URL and the served account disagree.
- Naive auto-reload on mismatch risks an infinite refresh loop.
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 →