Agent Context Isolation Seems to Break During Skill Usage

[nemo_nemini (nemo)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I’m seeing cross-session context leakage between agent sessions.

In one Cursor agent session, I ran a PR review command with only a GitHub PR target (/pr-review …/pull/352).
The agent correctly posted the GitHub review, but also posted to an unrelated Slack thread that belonged to a different, supposedly isolated agent session.

That Slack thread URL was not part of my explicit request in this session. It appears stale command/context data from another session was injected and treated as active input.

Agent used Slack context from another session and posted a thread reply.
Breaks session isolation.
Can cause accidental external messages/data leakage across parallel agent workflows.

Steps to Reproduce

I’m using a fairly complex pr-review skill which can accept various arguments (including GitHub links and Slack thread links)

1. Start Agent Session A.
2. In Session A, run a review flow that includes a Slack thread/permalink context (or causes Slack context to be stored in session state).
3. Start Agent Session B (intended to be isolated).
4. In Session B, run a PR review command with only a GitHub PR URL (no Slack link in the user message), e.g. /pr-review https://github.com/<org>/<repo>/pull/<id>.
5. Approve posting when prompted.
6. Observe that Session B posts to Slack thread from Session A (unexpected side effect), even though Session B input did not request Slack output.

Expected Behavior

Agent should only act on inputs explicitly provided in the current session/message.
No external side effects (Slack posts) unless explicitly requested in that session.

Operating System

MacOS

Version Information

Version: 3.6.31
VS Code Extension API: 1.105.1
Commit: 81fcf2931d7687b4ff3f3017858d0c6dee7e2a60
Date: 2026-05-31T17:46:29.630Z
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
xterm.js: 6.1.0-beta.220
OS: Darwin arm64 24.3.0

For AI issues: which model did you use?

gpt 5.5

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

[nemo_nemini (nemo)]

Attaching screenshots and recordings here because the initial submission form only allows one thing max (replaces previous uploads with the new ones).

[mohitjain (Mohit)]

Thanks for the detailed write-up and screenshots, and I can see why the second review chat acting on a Slack thread looked surprising.

There are likely two separate things in play here, and only one of them is on the Cursor side:

1. Chats in the same window share workspace context. When you run multiple chats in the same workspace/window, each chat can draw on context from your other recent chats and files in that workspace. That’s expected behavior, and it stays within your own machine and workspace - nothing crosses between accounts or users. This is the most likely reason a Slack thread from one review chat became visible to another chat that didn’t reference it directly. For workstreams you want kept fully separate, the most reliable approach today is to run each one in its own Cursor window pointed at its own folder (or worktree), so each chat has its own view.

2. The Slack reply itself most likely came from the review workflow’s own logic. A pr-review flow that posts a Slack update whenever it detects Slack context will tend to act on whatever context is available to it - so if a Slack thread is present in the shared workspace context, that step can run even when you didn’t pass a Slack link in that message. A couple of adjustments make the behavior deterministic regardless of what a given chat can see:

• Have the Slack step post only when a Slack link is supplied in that specific message (e.g. an explicit --slack <url> argument), rather than acting on any Slack context that’s in scope.

• It’s worth checking whether the workflow keeps a Slack thread reference around between runs (for example, saved to a file). If a previous run’s thread value is still available, a later run can reuse it - scoping or clearing that per run avoids it.

To help me confirm the Cursor-side piece: were both chats open in the same Cursor window/workspace? If they were, and the workflow doesn’t hold onto a Slack thread reference between runs, share the request IDs from each chat and I’ll take a closer look at how the workspace context was assembled.