a PR created by cloud agent (not automation) is currently attributed to me. i’d like it to be attributed to cursor or cursor[bot] or whatever, but not myself. comments are already submitted like this, i don’t understand why PRs are not.
i found the thread in this forum discussing this matter, but that was about PR created by automations, not cloud agents (apparently there’s a difference?).
extensive research points at GitHub Cursor app (account-wide) vs something called “personal Oauth token”, but i can’t figure out the difference nor how to configure which one will be used when and where. please advise.
Hey, thanks for the request. There are two different GitHub identities in play, and they’re used for different jobs:
Cursor GitHub App install at the account or org level gives Cursor access to repos. It’s used for push tokens, PR comments, Bugbot, and Automations. Anything done through it shows up as cursor[bot].
Personal GitHub connection via OAuth is your GitHub account connected in Cursor. It’s used when Cursor acts on your behalf. Creating a PR via the interactive Cloud Agent uses this, so the PR author is you.
This is intentional. A PR opened by an agent you started is attributed to you for ownership and review governance. If the PR were authorized by the bot, you could approve your own PR, and a few teams flagged that as an issue. The commits still show as Cursor Agent [email protected] with you as co-author.
The difference you noticed is that Automations run under the GitHub App identity, so their PRs come from the app. Interactive Cloud Agent runs do not.
There’s no UI toggle to change this for interactive runs right now. By default, app identity is used for agents started via a service account API key or via Automations. If you need PRs to come from the Cursor app, that’s the right path.
I get that you’d want this to be configurable by default. I’ll pass this to the team as a request for an opt-in toggle. Let me know if you want help setting up runs via a service account or Automations.
When someone @mentions Cursor in Slack, the Cloud Agent opens the GitHub PR under that person’s identity, using their GitHub OAuth.
On the other hand, I have an Automation where a PR is created when someone replies yes in Slack. Team-owned Slack Automations always open PRs as cursor[bot], even when a teammate is the one who replied yes.
It would be really useful to support both options. For example, the Automation could ask the person whether they want the PR created under their own name or under the bot’s name.
There are cases where a PR is more complex and it makes sense for the person who triggered it to own it and have several people collaborate on the review. In other cases, it would be better for the bot to be the author, with just one person reviewing and merging it.
So it would be great to have an option like:
“Open PRs as the triggering Slack user” (when that Slack user has Cursor + GitHub OAuth linked)
This would give us more flexibility to choose the right PR ownership model depending on the type of work.
Hey, thanks for the feature request, and for outlining both scenarios. That’s helpful context.
You’ve got the current behavior right: the interactive Cloud Agent opens a PR under the identity of the user who started it using personal GitHub OAuth, while team-owned Slack Automations always open PR under the GitHub App identity, meaning cursor[bot]. This is intended behavior, not a limitation specific to your setup.
What you’re suggesting, the ability to choose the authorship model, opening PRs as the triggering Slack user or as the bot depending on the type of work, is exactly what I passed to the team as a request. It’s something we’re tracking, but I can’t share a specific timeline.
If you need some tasks to open PRs under a specific identity right now, tell me and I’ll help you pick a configuration. The identity defaults differ depending on whether you run via a service-account API key or via Automations. Let me know.
Being able to configure the author for teams that want the Cursor Agent to be creating the PRs would be phenomenal. I get teams that don’t want that for them, but having the option to opt-in can be a game changer to switch away from other platforms/custom implementations that do let you do this.
Hey, thanks for joining the discussion. This is exactly the scenario I already shared with the team as a request for an opt-in author choice for interactive Cloud Agent PRs. We’re tracking it, but I can’t share a specific timeline yet.
To clarify the context, here’s the current default behavior. Interactive Cloud Agent opens PRs under the personal GitHub OAuth of whoever started it, so the PR author is the user. Automations and runs via a service-account API key use the GitHub App identity, so the PR comes from cursor[bot]. That’s intended behavior, not a limitation of a specific setting.
So if you need some tasks to open PRs as the Cursor app instead of the user right now, you can do that via Automations or a service-account key. Tell me what your setup looks like, and I’ll help you pick the right configuration for the author you want.
Hey, good question. A run via a service account API key means you’re starting a Cloud Agent through the Cloud Agents API. In the Authorization: Bearer ... header you pass a service account key, not your personal key or an interactive run.
Let’s break it down:
A service account is a separate non human account available on the Enterprise plan. It has its own API key that isn’t tied to a specific developer. More details: Service Accounts | Cursor Docs
When an agent starts using that key POST /v1/agents or /v0/agents with a service account key, it opens a PR by default under the Cursor GitHub App identity. So the PR author will be cursor[bot].
By contrast, an interactive run from the IDE or web under your user uses your personal GitHub OAuth. So the PR author is you.
So a service account run is not the same as a normal IDE run. It’s specifically an API call using a service account key.
Extra note: via the API you can control this directly using the openAsCursorGithubApp field in the request. By default it’s true for service account keys and false for user keys, but you can set it explicitly. API details: Cloud Agents API | Cursor Docs
One more nuance: service accounts are an Enterprise feature. Let me know what plan you’re on and how you’re starting agents right now IDE, Slack, or API, and I can suggest the right setup to get the PR author you want.