chore: remove posthog-code-slack-availability flag and tasks API gating#60960
Merged
VojtechBartos merged 4 commits intoJun 2, 2026
Merged
Conversation
VojtechBartos
force-pushed
the
vojtab/remove-tasks-and-slack-availability-flags
branch
from
e3c1b2a to
a4fc88b
Compare
Contributor
|
Size Change: -6.24 kB (-0.01%) Total Size: 80.9 MB 📦 View Changed
ℹ️ View Unchanged
|
VojtechBartos
force-pushed
the
vojtab/remove-tasks-and-slack-availability-flags
branch
from
a4fc88b to
b8b943e
Compare
Contributor
|
Reviews (1): Last reviewed commit: "chore(tasks): remove tasks feature flag ..." | Re-trigger Greptile |
joshsny
reviewed
Jun 1, 2026
| User has access to PostHog Code if the `tasks` feature flag is enabled for them | ||
| OR they have redeemed an invite code. | ||
| """ | ||
| def is_posthog_code_user(user: User) -> bool: |
Contributor
There was a problem hiding this comment.
we shouldn't be modifying this function, this should keep the tasks flag for backwards compatibility
| PersonalAPIKeyAuthentication, | ||
| OAuthAccessTokenAuthentication, | ||
| ] | ||
| permission_classes = [IsAuthenticated, APIScopePermission, TasksAccessPermission] |
Contributor
There was a problem hiding this comment.
it should be fine to remove the permission here on the API so long as we're still returning has access based on the flag / code invite check, cc @PostHog/team-posthog-code so you are aware
Contributor
|
✅ Visual changes approved by @VojtechBartos — baseline updated in 98 changed. |
![veria-ai[bot]](https://avatars.githubusercontent.com/in/1723776?s=60&v=4){kind=small}
| OAuthAccessTokenAuthentication, | ||
| ] | ||
| permission_classes = [IsAuthenticated, APIScopePermission, TasksAccessPermission] | ||
| permission_classes = [IsAuthenticated, APIScopePermission] |
There was a problem hiding this comment.
Medium: Task API access gate removed
An authenticated project member who has not redeemed a PostHog Code invite can now create tasks, start task runs, create automations, and configure sandbox environments because the only remaining checks are authentication, API scope, and project access. These endpoints trigger cloud agent workflows and sandbox execution, so keep an explicit PostHog Code entitlement check on the task, task run, automation, and sandbox viewsets if invite redemption is still the access boundary.
| return ROUTE_HANDLED_LOCALLY | ||
| candidates = enabled | ||
| target = result.integration if result.integration in enabled else None | ||
| candidates = result.candidates |
There was a problem hiding this comment.
Medium: Slack mentions can start Code workflows without an access gate
A Slack user whose email maps to a project member can now mention @PostHog in any workspace with the normal Slack integration and start a PostHog Code workflow; the workflow later creates runs with PR creation enabled and full MCP scopes. Add a PostHog Code access check before _start_command_workflow / _start_mention_workflow, or in the user-resolution activities, so Slack cannot bypass the same entitlement expected by the Code access check.
PR overviewThis PR removes the There are still open access-control concerns: authenticated project members, or Slack users mapped to such members, may be able to start PostHog Code workflows without the intended invite or entitlement check. Because these workflows can launch cloud agent activity, sandbox execution, and PR-capable runs, the remaining risk is meaningful even though it is limited to users already associated with a project or mapped through Slack. Open issues (2)
Fixed/addressed: 0 · PR risk: 6/10 |
VojtechBartos
force-pushed
the
vojtab/remove-tasks-and-slack-availability-flags
branch
from
b8b943e to
dfe5b08
Compare
VojtechBartos
added
the
update-snapshots
joshsny
approved these changes
Jun 1, 2026
The flag is fully rolled out. Drop the per-candidate filter in the app_mention router, the constant and helpers in slack_app api, the frontend constant, and the flag-related test cases.
Drops the PostHogCodeSlackIntegration component, its settings entry, and the now-orphaned kea selectors. The slack-posthog-code integration itself stays — only the project-settings UI is removed.
The tasks API no longer requires the dedicated PostHog Code access permission — has_tasks_access still answers the access question for the check-access endpoint and the slack post-update deep-link gate, but the viewsets themselves rely on the usual auth + scope stack.
VojtechBartos
force-pushed
the
vojtab/remove-tasks-and-slack-availability-flags
branch
from
dfe5b08 to
b31624e
Compare
98 updated Run: 3a855c61-fc8b-4595-8dcf-ee9bc2f70a34 Co-authored-by: VojtechBartos <1526646+VojtechBartos@users.noreply.github.com>
VojtechBartos
deleted the
vojtab/remove-tasks-and-slack-availability-flags
branch
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Two flags had outlived their usefulness:
posthog-code-slack-availabilitywas the cohort gate for the PostHog Code Slack surface. The feature is rolling out broadly, so the per-candidate filter and the dedicated settings UI no longer need to exist.tasksflag also gated the tasks backend API viaTasksAccessPermission. The backend should not be gated at all — invite redemption alone designates a PostHog Code user, and thetasksflag now only governs the frontend URL/tree entries for the Tasks scene.Changes
Three commits:
chore(slack_app): remove posthog-code-slack-availability flag— drops the per-candidate filter in theapp_mentionrouter, the constant + helpers inproducts/slack_app/backend/api.py, the frontendFEATURE_FLAGS.POSTHOG_CODE_SLACK_AVAILABILITYconstant, and the related test cases.chore(slack_app): remove posthog code slack settings UI— deletesPostHogCodeSlackIntegration.tsx, its entry inSettingsMap.tsx, both ids intypes.ts, and the now-orphanedposthogCodeSlackIntegrations/posthogCodeSlackAvailablekea selectors. Theslack-posthog-codeintegration kind itself stays — only the project-settings UI is removed.chore(tasks): remove tasks feature flag from backend—TasksAccessPermissionis gone from every tasks viewset,has_tasks_accessis renamed tois_posthog_code_userand answers solely fromCodeInviteRedemption. Thecheck_accessendpoint and the slack post-update deep-link gate consume the renamed helper.FEATURE_FLAGS.TASKSand theflag: FEATURE_FLAGS.TASKSmanifest entries are intentionally kept for frontend URL gating.How did you test this code?
Tested locally.
Automatic notifications
🤖 Agent context
Claude.