@cursor does nothing when mentioned on bot PR comment

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Background Agent (GitHub, Slack, Web, Linear)

Describe the Bug

We have bots that raise PR (powered by the Cursor CLI agent and GitHub workflows behind the scenes). If I @cursor myself in the comment thread in one of these bot PRs, nothing happens. If I @cursor in the comment thread of a human-raised PR, then the eyes emoji appears and Cursor does its thing.

Is this behaviour deliberate? Given that it is a human posting the comment, it shouldn’t matter how the original PR was raised.

It means that to work on the PR, I have to actually check the code out locally and use the Cursor IDE, which is frustrating, especially if it’s just a small fix.

Steps to Reproduce

Have a GitHub App bot create a PR. Then as a human, go to that PR comment thread, and @cursor to change something on the PR.

Expected Behavior

I would expect Cursor to spin up a cloud agent and do the work.

Operating System

MacOS

Version Information

It’s the GitHub app, so my Cursor IDE or CLI are not in the flow.

Does this stop you from using Cursor

No - Cursor works, but with this issue

3

Hey, thanks for the report. Good catch. If the comment is from a human, it should trigger no matter who created the PR.

A couple of questions to narrow this down:

  1. What type of bot creates the PR? Is it a GitHub App, a GitHub Action bot, or something like Dependabot? If it’s a custom GitHub App, what’s its name?
  2. When you @cursor on a bot PR, do you see zero reaction, like no eyes emoji and no comment, or does something partially happen?
  3. Can you share a link to an example bot-created PR where @cursor didn’t respond?

I’ll flag this to the team once I have more context. In the meantime, like you already found, checking out locally is the workaround.

4

Answers below. Did a change get pushed on your end, though, because I can now @cursor comment on bot threads, and Cursor kicks in as expected

  1. It is a custom GitHub app, private to our organisation. We just use this app as an identity, ironically, to work around the limitations that Cursor and other vendors place on interaction with other bot outputs. The app’s identity is used in GitHub Actions workflows via the actions/create-github-app-token@v2 action to generate a token. Our workflow then installs and invokes Cursor CLI agent as follows:

shell: bash
env:
CURSOR_API_KEY: ${{ inputs.cursor_api_key }}
GH_TOKEN: ${{ steps.app-token.outputs.token }}
MODEL: ${{ inputs.model }}
run: |
agent -p “$(cat /tmp/agent-prompt.txt)” --force --model “$MODEL” --output-format=text 2>&1 | tee /tmp/agent-response.txt
exit "${PIPESTATUS[0]}”

  1. Zero reaction (previously, now working)

  2. We have no open PRs with this issue, as we have resolved them all by hand. Here is one that now works, with the same bot user as was causing problems previously: https://github.com/mandai-x/edu-rbwe/pull/1532

Thanks,

Robin

Restricted
5

Hey @Robin_Weston glad to hear it’s working now. We did make some recent improvements to how the GitHub integration handles bot-authored PRs, and it looks like your case was covered by one of those changes.

If it happens again, feel free to share a link to the affected PR here. That makes it much easier for us to investigate on the backend.

6

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.