feat: flags and rpc for frontend code search tool

[shruthilayaj]

• When the flag is enabled, sets enable_frontend_code_search: true in seer chat request
• The frontend code search needs to know the feature flags enabled for an org - so this PR adds a get_organization_features RPC endpoint that returns all active api_expose=True flags. Seer can call this on demand to validate what features are enabled in the user's Sentry frontend

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

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

[cursor]

Duplicated feature-checking logic from organization serializer

Low Severity

The new get_organization_features function duplicates the batch-then-fallback feature-checking logic already present in src/sentry/api/serializers/models/organization.py (lines 462–497), including the _ORGANIZATION_SCOPE_PREFIX constant, the features.all() + batch_has + has(skip_entity=True) pattern, and the prefix-stripping step. Extracting this shared logic into a common utility would reduce the maintenance burden and the risk of the two implementations diverging.

 

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

[sentry-warden]

Caller-controlled user_id in get_organization_features lets org members evaluate api-exposed feature flags as arbitrary users

OrganizationSeerRpcEndpoint._dispatch_to_local_method only strips organization_id from the caller-supplied arguments dict before forwarding to get_organization_features, so an authenticated org member can include an arbitrary user_id in the request body. That id is loaded via user_service.get_user and used as the actor for features.batch_has/features.has, allowing the caller to learn which api_expose_only org feature flags evaluate true for any user id (e.g. flags gated on staff/superuser/per-user rollout). The dispatch should ignore caller-supplied user_id and pass request.user.id instead.

Evidence

• get_organization_features(*, org_id, user_id=None) in seer_rpc.py resolves actor = user_service.get_user(user_id=user_id) and uses it for every features.batch_has / features.has call.
• OrganizationSeerRpcEndpoint._dispatch_to_local_method (organization_seer_rpc.py) only does arguments.pop("organization_id", None) and then method(**arguments) with organization_id reinjected; user_id from the request body is forwarded unchanged.
• The registered wrapper map_org_id_param(get_organization_features) (utils.py) renames organization_id→org_id and forwards all other kwargs (return func(**kwargs)), so the attacker-controlled user_id reaches the sink.
• Request args are taken from request.data.get("args", {}) in post(), fully attacker-controlled JSON; the endpoint requires only org-member scope (SeerRpcPermission org:read/write/admin) plus the organizations:seer-public-rpc feature.
• Disclosed surface is limited to api_expose_only=True org-prefixed flags, but per-user gating (staff/superuser/rollout) means the result still leaks info about arbitrary users.

_{Identified by Warden security-review · 4HU-EW8}