From Greptile review triage of #377 (validated): hub_agents has a nullable user_id with no default, and its SELECT RLS policy is user_id = auth.uid(). Server-registered agents (service_role path, the normal tb.hub flow) have user_id = NULL, which never matches any auth.uid() — so authenticated web/Realtime clients will see an empty agent list.
Unlike the other hub tables, hub_agents has no tenant_workspace_id, so the workspace-membership policy pattern is unavailable without a schema change.
Not a problem for Phase 4.3 (server-side access uses service_role and bypasses RLS), but it silently blocks any Phase 4.4/4.6 web surface that lists workspace members.
Suggested direction: add tenant_workspace_id to hub_agents and adopt the workspace_member_read_* policy pattern used by the other hub tables.
Ref: migration supabase/migrations/20260611000000_add_hub_coordination_tables.sql (hub_agents SELECT policy).
From Greptile review triage of #377 (validated):
hub_agentshas a nullableuser_idwith no default, and its SELECT RLS policy isuser_id = auth.uid(). Server-registered agents (service_role path, the normal tb.hub flow) haveuser_id = NULL, which never matches anyauth.uid()— so authenticated web/Realtime clients will see an empty agent list.Unlike the other hub tables,
hub_agentshas notenant_workspace_id, so the workspace-membership policy pattern is unavailable without a schema change.Not a problem for Phase 4.3 (server-side access uses service_role and bypasses RLS), but it silently blocks any Phase 4.4/4.6 web surface that lists workspace members.
Suggested direction: add
tenant_workspace_idtohub_agentsand adopt theworkspace_member_read_*policy pattern used by the other hub tables.Ref: migration
supabase/migrations/20260611000000_add_hub_coordination_tables.sql(hub_agents SELECT policy).