Reported by Jay while approving three new agent identities on 2026-07-21.
What happens
After approving new agents onto a project, the Members view shows them in a separate group at the top, visually detached from the existing members. Closing the Projects app and reopening it renders them correctly, grouped with everyone else.
Why it matters more than a cosmetic glitch
It reads as a semantic distinction that does not exist. The natural interpretation of a separately grouped block is that those members are a different kind of member, and Jay reasonably asked whether the new agents had been added as native rather than external. They had not: all four build lanes carry identical values (origin=external-selfjoin in the registry, member_kind=native on the project). Verifying that took two API calls against two endpoints.
So a rendering artifact caused a false suspicion about access control, which is the worst category of UI bug to have in a permissions surface.
Likely cause
Stale local state after the approval mutation: newly added members are appended to a list that is rendered before a refetch reconciles ordering or grouping. A remount fixes it, which points at the members list not being invalidated or resorted after the add.
Suggested fix
- Invalidate and refetch the members list after an approval, or insert into the correctly sorted position rather than appending.
- Add a component test that adds a member to a populated list and asserts the resulting order matches a fresh fetch.
Related worth considering separately
origin and member_kind are genuinely confusing side by side: an agent can be external-selfjoin by origin and native by membership, which sounds contradictory without knowing the two fields answer different questions (how the identity was created, versus what kind of member it is). Surfacing both together in the members view, or renaming one, would remove the ambiguity that this bug exposed.
Reported by Jay while approving three new agent identities on 2026-07-21.
What happens
After approving new agents onto a project, the Members view shows them in a separate group at the top, visually detached from the existing members. Closing the Projects app and reopening it renders them correctly, grouped with everyone else.
Why it matters more than a cosmetic glitch
It reads as a semantic distinction that does not exist. The natural interpretation of a separately grouped block is that those members are a different kind of member, and Jay reasonably asked whether the new agents had been added as native rather than external. They had not: all four build lanes carry identical values (
origin=external-selfjoinin the registry,member_kind=nativeon the project). Verifying that took two API calls against two endpoints.So a rendering artifact caused a false suspicion about access control, which is the worst category of UI bug to have in a permissions surface.
Likely cause
Stale local state after the approval mutation: newly added members are appended to a list that is rendered before a refetch reconciles ordering or grouping. A remount fixes it, which points at the members list not being invalidated or resorted after the add.
Suggested fix
Related worth considering separately
originandmember_kindare genuinely confusing side by side: an agent can beexternal-selfjoinby origin andnativeby membership, which sounds contradictory without knowing the two fields answer different questions (how the identity was created, versus what kind of member it is). Surfacing both together in the members view, or renaming one, would remove the ambiguity that this bug exposed.