Chat references other chat after using slash command

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

In one chat (we’ll call it chat A) I ran a slash command:

please /commit only the change to gitignore

Note that /commit is a team command.

In another chat (chat B) that’s running in parallel (in other words, both chats were already open), I ran:

/commit and push

The agent responded:

I see there’s no .gitignore changes currently staged or modified.

(This was because chat A had already committed .gitignore.)

Looking at the thoughts in chat B, it thought:

The user wants to commit and push. They mentioned “only the change to gitignore” and “as DX”.

This is extra alarming because I didn’t even say “as DX” in chat A. However, I have said it before in previous chats. This suggests that the slash command, or maybe just team commands, is retaining or accessing context aside from the current chat. Maybe it’s related to “memories”?

Steps to Reproduce

  1. Have team command (e.g. /commit)
  2. Open 2 chats
  3. In one chat, run e.g. /commit XYZ. Wait for it to finish.
  4. In the other chat, run /commit ABC
  5. The unexpected behavior is that the second chat will reference XYZ from the first chat

I haven’t reproduced.

Expected Behavior

The 2 slash commands should ONLY be sent the context from their own chats.

Operating System

Windows 10/11

Version Information

Version: 3.1.17 (user setup)
VSCode Version: 1.105.1
Commit: fce1e9ab7844f9ea35793da01e634aa7e50bce90
Date: 2026-04-19T19:33:58.189Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

Kimi K2.5

For AI issues: add Request ID with privacy disabled

Chat A: b91220ec-d9b4-409f-b535-1aaf7c8c4ccf
Chat B: d21ee794-b0eb-4fb2-bba4-c3227d59421b

Additional Information

I believe the team command does give “DX” as a possible prefix to commit messages, so it may have hallucinated that part. But “only the change to gitignore” is not a common message or pre-configured option.

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Hi Charles,

Thanks for the detailed report, the request IDs and the clear A/B chat setup are really helpful.

This is a known issue class where context from one chat session can bleed into another parallel session. We’ve seen similar reports and our team is aware. The fact that Chat B’s reasoning referenced both Chat A’s instructions (“only the change to gitignore”) and content from your team command definition (“as DX”) confirms this is cross-chat persistence rather than normal model behavior.

As a practical mitigation, avoid running the same slash command in parallel chats; running them sequentially should prevent contamination. If you notice stale context persisting even in new chats, restarting Cursor clears it.

I’ve flagged this with the relevant tracking for the team. Thank you for reporting it.

7

Thanks for the quick reply. Do you know if this applies to things like skills as well, or is it limited to slash commands?

8

Skills and slash commands use different pipelines, so the specific contamination you experienced with /commit across parallel chats shouldn’t apply to skills in the same way.

That said, if you do notice anything similar with skills in parallel chats, definitely report it and we’ll investigate. The same sequential workaround (avoiding parallel chats running the same skill) would apply as a precaution.

9

Thanks! I’m really only using slash commands at this point, and have just dipped my toe into hooks. I will definitely report if anything odd seems to happen in these other pipelines.