Feature Request: Cross-Window / Cross-Repo Agent Communication

Ideas Feature Requests
,
1

Feature request for product/service

Cursor IDE

Describe the request

Context

As a developer on Mac with Cursor, I often work on multi-repo projects: e.g. a web-repo (frontend) and an api-repo (backend), each open in a separate Cursor window. Each repo has its own AI Agent, settings, and AGENTS.md for context-specific behavior.

Problem

When one agent identifies a dependency on the other repo, there is no way for agents to coordinate. I become the manual relay: copy-pasting findings and requests between chats, which breaks flow and risks misalignment.

Concrete Example

Goal: Improve error handling in a frontend component so users see precise messages (e.g. “Invalid API key” instead of “Something went wrong”).

  1. Frontend Agent (web-repo) investigates and concludes: the backend must first return structured error responses for certain endpoints (e.g. { "error": { "code": "INVALID_KEY", "details": "..." } }).
  2. Frontend Agent cannot notify or collaborate with the Backend Agent in the other window.
  3. I manually copy the spec into the api-repo chat, implement, then copy the contract back to the web-repo to align the frontend.
  4. Any change to the contract requires the same manual handoff again.

Ideal Flow

  1. Frontend Agent sends a structured request to Backend Agent: “Update /users/{id} to return { \"error\": { \"code\": \"...\", \"details\": \"...\" } } on 4xx/5xx before I implement frontend parsing.”
  2. Backend Agent confirms or asks clarifying questions, implements, runs tests, and optionally commits.
  3. Frontend Agent is notified (or re-queried), pulls the updated contract, and aligns component logic and tests.

No copy-paste; both sides stay in sync.

Requested Capabilities

1. Cross-Window Agent Communication

  • Agents in separate Cursor windows (different workspaces) can message each other (e.g. via @api-repo-agent or a linked workspace name).
  • Messages can carry context: file paths, snippets, API schemas, error payloads, or links to specific chats.
  • Linking is explicit (e.g. “Link this workspace to api-repo”) so there is no cross-talk by default.

2. Tri-Party Group Chats

  • One shared chat with: Developer + Agent A (e.g. frontend) + Agent B (e.g. backend).
  • Developer can ask: “Backend Agent, confirm the error schema for /users; Frontend Agent, then add parsing for it.”
  • Agents can reference each other’s repo/context (with appropriate access) so contract and implementation stay aligned.
  • Optional: light sync via shared contract docs or AGENTS.md so both repos reference the same contract.

3. Repo Linking UX

  • Simple way to pair repos (e.g. “Link workspace” or drag api-repo into web-repo window).
  • Linked repos are bidirectional: Frontend Agent can request changes from Backend Agent and vice versa, without merging codebases or leaving Cursor.

Benefits

  • No manual relay: Backend–frontend sync, API-contract evolution, and microservices coordination happen through agent-to-agent communication.
  • Fewer bugs: Error schemas, status codes, and request/response shapes stay consistent across repos.
  • Scales: Works for split-stack (Next.js + Express, React + Go, etc.), monorepos with multiple agents, or many microservices.
  • Mac-friendly: Use Spaces or side-by-side windows per repo while agents collaborate in the background.

Technical Considerations

  • Transport: Lightweight, Cursor-internal channel (e.g. pub/sub or workspace-indexed message bus) so agents can send/receive without external services.
  • Privacy: Opt-in only. No data leaves the machine unless the user explicitly links workspaces or shares context. Linked state is local or under user-controlled storage.
  • Fallback: If linking is unavailable or fails, current workflow (manual copy-paste, single-window multi-folder) continues to work. Optional: @mention with paste-from-clipboard for a single manual handoff.
  • Offline / one window closed: Queued or best-effort delivery; clear indication when the other agent is unreachable.

Why This Matters for Cursor

Multi-repo and split-stack setups are common. Letting agents collaborate across repos turns Cursor into the default tool for cross-stack, AI-assisted development instead of forcing the human to be the only integration point.

Upvotes appreciated! Let’s make multi-agent, multi-repo workflows seamless.

Operating System (if it applies)

MacOS

3

I find myself doing the same thing.

4

@Richard_W Same here, and until Cursor ships something native, I’m using a workaround that has worked better for me than trying to automate cross-window chat.

Workaround: I added a skill under .cursor/skills that maps every repo in my project: short description of each one plus its absolute path. When an agent needs logic or contracts from another repo, it can read those paths and pull the context itself instead of me guessing paths or pasting trees.

If I need one agent to brief another repo’s agent, that skill gives enough shared vocabulary (what lives where, how things connect) that the handoff stays aligned—I still paste or switch chats, but the message is usually complete on the first try.

I also prototyped a small CLI on top of Cursor’s MCP to send/receive messages across windows/repos. It worked technically, but the UX didn’t beat plain copy‑paste for speed or clarity, so I dropped it.

The skill-based approach has been the fastest and most reliable option so far. I’m still hoping Cursor picks this up—cross-repo coordination feels very achievable as a first‑party feature.

Hope it will help