[Feature Request] Cross-project agent communication and event broadcasting

Resolved 💬 3 comments Opened Mar 25, 2026 by padrian2s Closed Mar 29, 2026

Bug Description
Hi Claude Code team,

First off — Claude Code is genuinely impressive, and the multi-agent support within a single project instance is a real productivity boost. But I want to raise what I believe is a significant gap that, if addressed, would be a game changer: cross-project agent communication on the same machine.

---

The Problem

Today, when running multiple Claude Code instances across different projects on the same computer, each agent is completely siloed. Agents within a single project can collaborate, which is great — but the moment a change in Project A needs to trigger awareness or action in Project B, you're on your own. There's no native mechanism for one agent to signal, notify, or pass context to another agent living in a different project workspace.

---

A Concrete Use Case

Imagine a monorepo-adjacent setup where you have:

  • Project A — a shared component library
  • Project B — a frontend app consuming that library
  • Project C — a backend API that the frontend calls

An agent working in Project A refactors a core UI component — changes its props interface, renames exports, updates types. Right now, the agent in Project B has no idea this happened. A developer has to manually context-switch, re-brief the Project B agent, and re-explain the upstream changes.

With cross-project communication, the Project A agent could broadcast a structured change event — "Component <Button> updated: prop type renamed to variant, new required prop size added" — and the Project B agent would receive it, automatically adapt its codebase, and even flag conflicts proactively. Project C's agent could similarly be notified if any shared API contracts changed.

This kind of orchestration turns isolated agents into a coordinated development team.

---

Why It Matters

Modern software is rarely a single project. Microservices, shared libraries, design systems, monorepos split into workspaces — these are the norm. The pain of context fragmentation across projects is exactly where developer productivity breaks down, and it's currently a blind spot for AI coding agents.

The building blocks could be lightweight: a local pub/sub bus, a shared named pipe, a structured event log in a known directory (e.g., ~/.claude/ipc/), or even a simple local socket. Agents could subscribe to topics (by project name or tag) and emit typed events when meaningful changes occur.

---

Why This Would Be a Game Changer

  • Eliminates the tax of manually re-briefing agents on upstream changes
  • Enables true multi-project agentic workflows on a single dev machine
  • Unlocks autonomous refactor propagation across dependent codebases
  • Makes Claude Code viable as the backbone of a full local development ecosystem, not just a per-project assistant

The multi-agent support you've already built shows the vision is there. Cross-project IPC feels like the natural next step to make that vision fully realized.

Thanks for building something this powerful — excited to see where it goes.

Best,

Adrian

Environment Info

  • Platform: darwin
  • Terminal: iTerm.app
  • Version: 2.1.83
  • Feedback ID: 05bb585f-5b2f-4f57-8213-be4fe8566fad

Errors

[{"error":"Error: unable to verify the first certificate\n    at from (/$bunfs/root/src/entrypoints/cli.js:71:14396)\n    at <anonymous> (/$bunfs/root/src/entrypoints/cli.js:79:12938)\n    at emitError (node:events:43:23)\n    at <anonymous> (/$bunfs/root/src/entrypoints/cli.js:78:1149)\n    at emitError (node:events:43:23)\n    at <anonymous> (node:_http_client:253:22)\n    at processTicksAndRejections (native:7:39)\n    at request (/$bunfs/root/src/entrypoints/cli.js:81:2467)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-03-25T06:48:09.034Z"},{"error":"Error: unable to verify the first certificate\n    at from (/$bunfs/root/src/entrypoints/cli.js:71:14396)\n    at <anonymous> (/$bunfs/root/src/entrypoints/cli.js:79:12938)\n    at emitError (node:events:43:23)\n    at <anonymous> (/$bunfs/root/src/entrypoints/cli.js:78:1149)\n    at emitError (node:events:43:23)\n    at <anonymous> (node:_http_client:253:22)\n    at processTicksAndRejections (native:7:39)\n    at request (/$bunfs/root/src/entrypoints/cli.js:81:2467)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-03-25T06:49:32.398Z"},{"error":"Error: unable to verify the first certificate\n    at from (/$bunfs/root/src/entrypoints/cli.js:71:14396)\n    at <anonymous> (/$bunfs/root/src/entrypoints/cli.js:79:12938)\n    at emitError (node:events:43:23)\n    at <anonymous> (/$bunfs/root/src/entrypoints/cli.js:78:1149)\n    at emitError (node:events:43:23)\n    at <anonymous> (node:_http_client:253:22)\n    at processTicksAndRejections (native:7:39)\n    at request (/$bunfs/root/src/entrypoints/cli.js:81:2467)\n    at processTicksAndRejections (native:7:39)"…

Note: Content was truncated.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗