feat(workspaces): gate workspace forking behind runtime workspace-forking feature flag

[waleedlatif1]

Summary

• Added a runtime workspace-forking feature flag (AppConfig-backed on Sim Cloud, secret fallback off-AppConfig) so we can dark-launch workspace forking to specific orgs/users/admins without a redeploy.
• Gated the shared assertForkingEnabled choke point (fork/promote/rollback) on the flag with { userId, orgId } context; an off/absent flag 404s so a newer image never silently exposes forking. The Enterprise-plan entitlement still applies on top on Sim Cloud.
• Reused the existing FORKING_ENABLED secret as the flag's fallback — no new env var, and self-hosted behavior is unchanged.

Notes

• The client mirror (useForkingAvailable) can't see the flag (there is no client AppConfig), so during a dark-launch an Enterprise org may briefly see fork UI that 404s until the flag is enabled. This is the standard dark-launch tradeoff; the server gate remains the security boundary.
• Operators: add workspace-forking to the hosted feature-flags AppConfig document and run a sim-<env>-fast deployment to roll out.

Type of Change

• New feature

Testing

• Added unit coverage for the flag's fallback-secret path and AppConfig org/user targeting.
• Full typecheck clean (0 errors), feature-flags.test.ts passes (15/15), biome clean.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Jun 30, 2026 5:27am

[cursor]

PR Summary

Medium Risk
Changes authorization for Enterprise fork/promote/rollback routes on Sim Cloud; misconfigured AppConfig could deny or partially expose forking until rollout is correct, though existing plan/env gates remain.

Overview
Adds a workspace-forking runtime feature flag (AppConfig on Sim Cloud, FORKING_ENABLED fallback elsewhere) so operators can dark-launch fork/promote/rollback to selected orgs/users without redeploying.

assertForkingEnabled now takes userId and, when AppConfig is enabled, requires isFeatureEnabled('workspace-forking', { userId, orgId }) after the existing deployment/Enterprise gates; a disabled flag returns 404. Self-hosted behavior stays tied to FORKING_ENABLED when AppConfig is off.

Unit tests cover the fallback secret path and AppConfig org/user targeting for the new flag.

^{Reviewed by Cursor Bugbot for commit 8323162. Configure here.}

[greptile-apps]

Greptile Summary

This PR adds a runtime gate for workspace forking. The main changes are:

• Adds a workspace-forking feature flag with FORKING_ENABLED fallback.
• Checks the flag in the shared fork, promote, and rollback authorization path.
• Adds tests for fallback-secret behavior and AppConfig org/user targeting.

Confidence Score: 5/5

This looks safe to merge.

• No blocking issues found in the changed code.

Important Files Changed

Filename	Overview
apps/sim/lib/core/config/feature-flags.ts	Adds the workspace-forking flag definition and fallback mapping.
apps/sim/lib/core/config/feature-flags.test.ts	Adds tests for fallback and AppConfig targeting behavior.
apps/sim/lib/workspaces/fork/lineage/authz.ts	Adds the runtime feature-flag check to the shared forking authorization gate.

_{Reviews (2): Last reviewed commit: "fix(workspaces): scope workspace-forking..." | Re-trigger Greptile}

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 8323162. Configure here.}