⚠️ Potential issue | 🟠 Major

Don’t gate this sidebar item by feature flag at nav level.

This hides the menu entry and diverges from the project’s established pattern where sidebar items are always shown and authorization is enforced in route loaders.

-import { useFeatureFlags } from "~/hooks/useFeatureFlags";
 import { useFeatures } from "~/hooks/useFeatures";
@@
   const { isManagedCloud } = useFeatures();
-  const featureFlags = useFeatureFlags();
@@
-          {featureFlags.hasPrivateConnections && (
-            <SideMenuItem
-              name="Private Connections"
-              icon={LockClosedIcon}
-              activeIconColor="text-purple-500"
-              to={v3PrivateConnectionsPath(organization)}
-              data-action="private-connections"
-            />
-          )}
+          <SideMenuItem
+            name="Private Connections"
+            icon={LockClosedIcon}
+            activeIconColor="text-purple-500"
+            to={v3PrivateConnectionsPath(organization)}
+            data-action="private-connections"
+          />

Also applies to: 52-53, 110-118

Verify each finding against the current code and only fix it if needed.

In `@apps/webapp/app/components/navigation/OrganizationSettingsSideMenu.tsx`
around lines 12 - 13, The OrganizationSettingsSideMenu is currently hiding
sidebar items using feature-flag hooks (useFeatureFlags, useFeatures) at the nav
level; remove that gating so menu entries are always rendered and let
route/loader authorization handle access instead: update the
OrganizationSettingsSideMenu component to stop conditionally rendering the menu
item(s) based on useFeatureFlags/useFeatures (including the blocks around the
link(s) referenced in the component where features are checked) so the links are
always present, but keep any existing route-level guards intact.

⚠️ Potential issue | 🟠 Major

Guard the action with the same canAccessPrivateConnections check.

Line 47 gates only the loader. The delete action (Line 71 onward) is still callable directly and can mutate state without feature access, which weakens enforcement of the org-level flag.

 export const action = async ({ request, params }: ActionFunctionArgs) => {
   const userId = await requireUserId(request);
   const { organizationSlug } = OrganizationParamsSchema.parse(params);
+  const canAccess = await canAccessPrivateConnections({ organizationSlug, userId });
+
+  if (!canAccess) {
+    return redirect(organizationPath({ slug: organizationSlug }));
+  }
 
   if (request.method !== "DELETE" && request.method !== "POST") {
     return json({ error: "Method not allowed" }, { status: 405 });
   }

Also applies to: 71-113

Verify each finding against the current code and only fix it if needed.

In
`@apps/webapp/app/routes/_app.orgs`.$organizationSlug.settings.private-connections._index/route.tsx
around lines 47 - 49, The delete action is not currently protected by the same
org-level check as the loader; call canAccessPrivateConnections({
organizationSlug, userId }) at the start of the action handler (the export const
action or the function handling the delete flow around the deletion logic
starting at line ~71) and, if it returns false, short-circuit by returning a
redirect to organizationPath({ slug: organizationSlug }) (or an appropriate
unauthorized response) before performing any deletion or state mutation; ensure
you reference the same organizationSlug and userId used in the loader so the
guard logic is identical.

⚠️ Potential issue | 🟠 Major

Apply the same access gate in action to prevent direct POST bypass.

The loader is protected, but create mutation in Line 95+ is still reachable via direct form POST without feature access validation.

 export const action: ActionFunction = async ({ request, params }) => {
   const userId = await requireUserId(request);
   const { organizationSlug } = OrganizationParamsSchema.parse(params);
+  const canAccess = await canAccessPrivateConnections({ organizationSlug, userId });
+
+  if (!canAccess) {
+    return redirect(organizationPath({ slug: organizationSlug }));
+  }
 
   const formData = await request.formData();
   const submission = parse(formData, { schema });

Also applies to: 95-154

Verify each finding against the current code and only fix it if needed.

In
`@apps/webapp/app/routes/_app.orgs`.$organizationSlug.settings.private-connections.new/route.tsx
around lines 59 - 62, The POST/action handler must enforce the same access gate
as the loader: call canAccessPrivateConnections({ organizationSlug, userId }) at
the start of the action (before performing the create mutation), and if it
returns false perform the same redirect to organizationPath({ slug:
organizationSlug }) (or return an appropriate unauthorized response) to prevent
direct form POST bypass; update the action function in this file to reuse the
canAccessPrivateConnections check and short-circuit before running the mutation
logic that currently lives after line 95.

🚩 Managed cloud requirement intentionally dropped for private connections

The old hasPrivateConnections in features.server.ts:18-23 required BOTH PRIVATE_CONNECTIONS_ENABLED === "1" AND the host being managed cloud (isManagedCloud(host)). The new implementation in canAccessPrivateConnections.server.ts:24 and OrganizationsPresenter.server.ts:161 only checks the env var (or feature flag override), dropping the managed cloud gate. This means self-hosted instances with PRIVATE_CONNECTIONS_ENABLED=1 will now see Private Connections in the UI and be able to access the routes, which was previously blocked. This appears intentional (moving to per-org flag control), but is worth confirming since it broadens the feature surface.

Was this helpful? React with 👍 or 👎 to provide feedback.

⚠️ Potential issue | 🟠 Major

Return false when org lookup fails before evaluating the flag.

As written, this can return true from env default even when the user is not a member or the org slug doesn’t exist. That makes the helper semantically unsafe as an access primitive.

   const org = await prisma.organization.findFirst({
@@
   });
 
+  if (!org) {
+    return false;
+  }
+
   const flag = makeFlag();
   return flag({
     key: FEATURE_FLAG.hasPrivateConnections,
     defaultValue: env.PRIVATE_CONNECTIONS_ENABLED === "1",
-    overrides: (org?.featureFlags as Record<string, unknown>) ?? {},
+    overrides: (org.featureFlags as Record<string, unknown>) ?? {},
   });

Verify each finding against the current code and only fix it if needed.

In `@apps/webapp/app/v3/canAccessPrivateConnections.server.ts` around lines 11 -
26, The org lookup can be null which should short-circuit access; change the
flow in the code that calls prisma.organization.findFirst (variable org) so that
if org is falsy you immediately return false instead of evaluating the feature
flag; keep using makeFlag and FEATURE_FLAG.hasPrivateConnections only when org
exists and pass overrides from org.featureFlags, but do not fall back to
env.PRIVATE_CONNECTIONS_ENABLED for non-members or missing orgs.

🚩 makeFlag override fix changes behavior for falsy org flag values across all callers

The change from if (opts.overrides?.[opts.key]) (truthy check) to if (opts.overrides?.[opts.key] !== undefined) at featureFlags.server.ts:52 is a correctness fix, but it subtly changes behavior for ALL existing callers of makeFlag, not just the new hasPrivateConnections code. Specifically, if any organization has a boolean flag like hasQueryAccess: false or hasAiAccess: false stored in their featureFlags JSON column, the old code would silently ignore this false override and fall through to the DB global value. The new code correctly respects the false override. I verified all existing callers (canAccessQuery, canAccessAi, canAccessAiModels, eventRepository, workerGroupService, runsRepository) — for non-boolean flags this has no effect, and for boolean flags the fix is the correct behavior. However, if any orgs have false flags that were previously being bypassed, they will now take effect.

Was this helpful? React with 👍 or 👎 to provide feedback.