Be able to request teams as reviewers in Automations

Ideas Feature Requests
, ,
1

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

Hi,

We are currrently using Cursor Automations to build flows which involves assignment of PR reviewer post creation of the PR by the automation. We were trying to use the in built reviewer assignment tool that comes along with Automation - Automations | Cursor Docs.

It works fine when the reviewer is an individual Github user. However its unable to assign a team as reviewer successfully, for example a Github team slug(org_name/team_slug). The automation is able to do this via gh CLI in the environment.

Steps to Reproduce

  • Have the automation create or work on existing PR.
  • Prompt to use the reviewer assignment tool to assign a team as reviewer giving the full slug of the team in the org.
  • The reviewer would be empty in the PR.

Expected Behavior

Assign the team as reviewer which is something you can do with gh CLI

Operating System

Other

Version Information

Not applicable

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Thanks for flagging this @mahesh-krishnakumar! It would make sense to be able to assign teams the same way you can reviewers.

I’ve shared that feedback with the team!

10

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

PR Routing & Approval is enabled on one repository through an organisation-level install of the Cursor GitHub App. The app has pull_requests: write and members: read. Our approval policies tell the agent to request the owning GitHub team for a change, so that the team’s code review assignment on GitHub picks the individual. Every team named in the policies has code review assignment enabled, and requesting one of them by hand works: GitHub swaps the team for a member within a second.

Steps to Reproduce

The agent runs, decides which team owns the change, and reports that it requested the team. GitHub never receives the request.

Run bc-e0022d3b-3b76-4b91-bedb-45acca37319d, 14 September 2026, PR marked ready for review at 20:47:25 UTC. The run summary shows the tool call Request reviewers: org/team-a, user-x. GitHub’s timeline for that PR has exactly one review request from cursor[bot], for user-x at 20:54:40. There is no request for org/team-a, and no failed attempt anywhere in the timeline. Five minutes later I requested org/team-a myself and GitHub immediately replaced it with a member.

A second PR the same day, marked ready at 13:12:34 UTC, touched two areas owned by two different teams. The agent’s review comment at 13:14:07 reads “Reviewers were requested for the owning teams.” GitHub’s timeline has no review request from cursor[bot] at all on that PR. The author requested people by hand at 13:20.

So the pattern is consistent across two runs: requests for individual users land, requests for teams are lost, and the agent reports success in both cases.

Expected Behavior

Either the team request reaches GitHub, or the tool returns an error so the agent can fall back to naming a member and say so in its comment. Silent success is the worst outcome, because the PR sits with no reviewer and the summary says it has one.

Operating System

Other

Version Information

Cursor Agents

Additional Information

Questions
Does the Request Reviewers tool support GitHub team slugs at all? The docs for PR Routing & Approval say the agent “assigns reviewers based on code ownership” but do not say whether teams are supported.
If teams are supported, is the app hitting the known GitHub behaviour where installation tokens get a 422 on team_reviewers, and if so, is that being swallowed rather than returned to the agent?
If teams are not supported, could the tool reject the slug so the agent knows, rather than dropping it?

Happy to share the repository, PR numbers and the second run id by DM, and to open test PRs on request.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

14

Hey @eng-apolitical!

Today the Request reviewers action only accepts individual GitHub usernames.

In the meantime, two ways to get the team’s review assignment working:

  1. Add the owning teams to CODEOWNERS on your base branch for the paths they own. GitHub will request the team itself when the PR is marked ready for review, and its review assignment picks the individual just like when you request the team by hand.
  2. Or, in your approval policies, list the GitHub usernames of the team members instead of the team slug, so the agent requests people directly.

I’ve moved your post into an existing thread requesting this same functionality for teams.

15

Thanks Colin, that clears it up, and the move to a feature request makes sense.

I’d like to make the case for team support rather than either workaround, because of what a team request unlocks on the GitHub side. We have code review assignment enabled on every squad team, set to load balance. When a team is requested, GitHub picks the member with the fewest outstanding reviews, skips people who are away, and records the whole thing in the PR timeline. That is exactly the piece we want the automation to hand off to: the agent decides which team owns the change and how risky it is, and GitHub decides which person has capacity. Requesting a team is one call; the load balancing comes free.

The two workarounds each give that up:

  • CODEOWNERS requests the team the moment the PR is marked ready, before the agent has run. So the team gets requested for every PR regardless of risk, the agent cannot add a second team for high-risk changes without it landing as a named person, and we end up maintaining the same path-to-team map twice, once in CODEOWNERS and once in the approval policies. It also stops being the agent’s decision at all.
  • Usernames in the policies turns the policy files into a duty rota. Every joiner, leaver and holiday becomes a policy PR, and we lose load balancing entirely, since the agent has no view of who has three reviews open already.

What would work for us is simply accepting org/team-slug in Request reviewers and passing it through as team_reviewers. Until then, returning an error for a slug instead of dropping it would already help a lot: the agent could fall back to naming someone and say so, rather than reporting reviewers requested when none were.

Happy to test a build of this on our repository whenever it’s available.