[bug] host-cloudflare: AccountProvider.me omits orgRole, so the console hides every workspace mutation from admins #1958

Activity

1. Stormix commented on Sep 11, 2026

   

   Stormix

   on Sep 11, 2026

   More actions

   I reproduced this on v1.6.8 (eaa1f3a57), self-hosted on Cloudflare Workers behind Access. My email was in ADMIN_EMAILS, but Add connection only showed Personal. My agent found a different approach, so I'm not 100% sure which one is the right fix for this:

   The UI’s admin check reads the account member list, and the Cloudflare provider hardcodes:

   listMembers: () => Effect.succeed({ members: [] }),

   So /api/account/members returns no membership from which the UI can determine the current user’s role.

   I patched apps/host-cloudflare/src/account/account-provider.ts to authenticate through its existing principalFrom(headers) helper and return the current principal as a member, with role: principal.orgRole ?? "member" and isCurrentUser: true.

   After deploying that change, Workspace ownership became available for connections and OAuth apps.
2. ray-amjad commented on Sep 17, 2026

   

   ray-amjad

   on Sep 17, 2026

   More actions

   Confirming this on v1.6.8 with the Cloudflare host behind Access, with the signed-in email in ADMIN_EMAILS. The root cause is listMembers, not me:

   • The console decides admin status in useIsTenantAdmin (packages/react/src/multiplayer/use-admin-nav.tsx) by finding the member row with isCurrentUser: true in /api/account/members.
   • apps/host-cloudflare/src/account/account-provider.ts hardcodes listMembers: () => Effect.succeed({ members: [] }), so that row never exists.
   • So useCanCreateWorkspaceConnections() is always false: the Saved to picker in Add connection is hidden and every new connection is Personal. The server already allows workspace writes for allowlisted admins (orgWriteAccessForPrincipal), so this is a UI-only gap.

   The fix from the previous comment works for us. listMembers resolves the Access principal with the existing principalFrom(headers) helper and returns it as the only member:

   listMembers: (headers) =>
     principalFrom(headers).pipe(
       Effect.flatMap((principal) =>
         principal
           ? Effect.succeed({
               members: [
                 {
                   id: principal.accountId,
                   userId: principal.accountId,
                   email: principal.email,
                   name: principal.name,
                   avatarUrl: principal.avatarUrl,
                   role: principal.orgRole === "admin" ? "admin" : "member",
                   status: "active",
                   lastActiveAt: null,
                   isCurrentUser: true,
                 },
               ],
             })
           : Effect.fail(new AccountUnauthorized()),
       ),
     ),

   It reports only the caller, never the rest of the Access directory, and the role matches what the API gate already grants, so non-admins still get Personal only. After deploying, /api/account/members returns one active admin row, Add connection shows Personal and Workspace, and a Workspace connection created through it is visible to other principals.

   Test (apps/host-cloudflare/src/account/account-provider.test.ts):

   const listMembers = (cfg: CloudflareConfig) =>
     Effect.gen(function* () {
       const provider = yield* AccountProvider;
       return yield* provider.listMembers({});
     }).pipe(Effect.provide(cloudflareAccountProvider(cfg)));
   
   it.effect("reports the caller as the current member with its gate role", () =>
     Effect.gen(function* () {
       const result = yield* listMembers({ ...config, enableDevAuth: true });
       expect(result.members).toHaveLength(1);
       expect(result.members[0]).toMatchObject({ role: "admin", status: "active", isCurrentUser: true });
     }),
   );
   
   it.effect("rejects a request with no Access assertion", () =>
     Effect.gen(function* () {
       const error = yield* Effect.flip(listMembers(config));
       expect(error._tag).toBe("AccountUnauthorized");
     }),
   );

   Happy to open a PR if that helps.
3. cheetahbyte commented on Oct 1, 2026

   

   cheetahbyte

   on Oct 1, 2026

   More actions

   Still affected by this on my Cloudflare deployment: my email is in ADMIN_EMAILS, but adding an integration shows “Requires a
   workspace admin.” I see #2089 is still open. Is anything blocking it from being merged?
4. RhysSullivan commented on Oct 8, 2026

   

   RhysSullivan

   on Oct 8, 2026

   Collaborator

   More actions

   We're clearing the backlog ahead of the v2 launch, so we're closing this. If it still applies to v2, please open a new issue or PR against v2.

   Sent from my Claude
5. RhysSullivan

   closed this as not plannedon Oct 8, 2026