Cursor Background Agent from Github creates new session on every follow up post

Where does the bug appear (feature/product)?

Background Agent (GitHub, Slack, Web, Linear)

Describe the Bug

It used to preserve the session and only create new one with @cursor agent. Right now, I see a session per @cursor <message> in the same issue. This breaks the context usage.

Steps to Reproduce

.

Operating System

MacOS

Version Information

CLOUD version

Does this stop you from using Cursor

Yes - Cursor is unusable

Hi @alexandrosandre!

What system are you calling @Cursor from? Slack? GitHub? Linear? Something else?

Hi @Colin

As mentioned Github issues. This is the official Cursor app for GitHub triggering the agent.

Thanks @alexandrosandre !

Follow-up @cursor messages that continue an existing session currently only work on Pull Requests, where the agent can identify the active session by the PR’s branch. On GitHub Issues, each @cursor mention starts a new, independent agent session.

Is it possible that the behavior you’re describing (session reuse) was something you experienced on Pull Requests? That would explain why it seemed to work before, but doesn’t on Issues.

That could really be the case that I have imagined the support for issues only because I saw it within PRs. I guess it makes sense in issues too,but is not a huge problem if the issue agent reads the full issue every time. Could you confirm this?

Thanks for the help. Maybe we can transform this into a feature request. That’s progress haha.

Shouldn’t be an issue! But I agree that it’s inconvenient if you’re working in an issue and get multiple Cloud Agents spun up (for reasons of latency, theoretically some token savings, and not having info spread out).

Out of curiosity, could you describe how you usually use agents on issues? Presumably those agents start making code changes, which would be hard to review and follow up on from the issue.

Hi @Colin,

Sure. We have two scenarios.

The first is the one you mentioned, where you ask Cursor to address the issue and receive a PR you can follow up then with Cursor Web or within that PR. That one works fine.

The second one is when you are asking Cursor to help by finding details about the issue, e.g. the bug report, to document it better, start a plan to address it, etc, but you are essentially still gathering context with AI but also with real users. This requires a contextual multi step flow the same session would provide.

The two scenarios collide when Cursor didn’t understand the issue and in a follow up prompt you refine, correct, etc.

I’m short, Cursor is not always the fixer right away, they may be the collaborator.

Hope this helps.