You open five Claude Code sessions. One rewrites auth, one fixes tests, one lands a shared-lib change. None of them know the others exist — until they collide on the same file, duplicate work, or sit blocked on a lock. Most agentic coding tools stop there. Power Claude and the hurc harness add something rare: a signed, local inter-session message bus so agents can coordinate like a real team.
TL;DR: Parent→child handoffs are not the same as peer sessions coordinating on one machine. Cross-session messaging is the missing layer for multi-top-level agent work.
The missing layer in agentic coding
Agentic coding in 2026 is good at one session doing many steps. It is still weak at many top-level sessions working the same machine without stepping on each other.
Vendors improved the parent → child path first. Claude Code's Task tool, Copilot agent handoffs, Cursor background agents, and similar patterns let one orchestrator spawn specialists. That is useful. It is not the same problem as:
- Two windows you started by hand on the same repo
- A Grok session and a Claude session on the same machine
- A parked worker that needs a heads-up from a live session
- An agent that should ask "are you still holding resolve.ts?" instead of waiting for a blind lock TTL
In most stacks, those sessions are islands. They share a filesystem and a git index. They do not share a coordination channel. Humans become the message bus: tab-switching, Slack notes to yourself, or hoping two agents do not edit the same module at once.
Inter-session messaging is the fleet layer most agent harnesses never shipped.
Power Claude surfaces it for Claude Code users. The engine itself lives in the hurc LLM harness — vendor-neutral, machine-wide, default-on when quiet, and signed so a peer cannot forge another session's identity.
Deep product surface: Power Claude → Cross-session messaging. Start the 14-day Premium Trial if you already run multi-session fleets.
What "sessions that talk" actually means
The capability is not chat spam between agents. It is a local, trust-gated bus with four jobs:
| Job | What it does for you |
|---|---|
| Peer messaging | Session A sends a signed note to session B (or broadcast) |
| Presence / peers | List who is live vs parked, which repo, how many messages queued |
| Work claims | Advisory ledger: "I am editing this file/symbol for this intent" |
| Lock negotiation | Ask the holder of a file lock for ETA / release instead of blind-waiting |
| Wake (optional) | Power Claude can re-open a parked session when a message arrives |
Receivers inject verified messages into the agent's context as untrusted peer data, never as system instructions. That framing is deliberate: a peer can be wrong, stale, or itself confused. The signature answers who sent it, not whether the body is safe to obey.
Why most agentic tools do not do this
1. Parent–child only (native "teams")
Claude Code agent teams and similar products let a parent message children it spawned. Independently launched top-level sessions still cannot address each other. If you open three tabs yourself, there is no native bus.
2. Human as orchestrator
You run agents in parallel and coordinate in your head. Works at two sessions. Falls apart at ten overnight workers.
3. Shared files without protocol
Agents "communicate" by writing markdown status files. No crypto, no presence, no quarantine, no rate limits, easy for one confused agent to clobber the protocol.
4. Cloud multi-agent frameworks
LangGraph, CrewAI, AutoGen and friends can do explicit inter-agent messaging — when you build the graph in Python and leave your daily coding surface. Most day-to-day Claude Code / Cursor / Codex / Grok users never wire that into the sessions they already run.
5. Nothing
The default. Parallel agents race. Merge conflicts and duplicate PRs teach you the hard way.
The hurc bus sits in a different niche: surface-agnostic, multi-session, same-machine, coding-agent fleet coordination — not a research multi-agent framework and not a chat product. IDE and CLI both participate. The bus is local files + hooks; VS Code is one consumer UX, not a hard requirement.
Concrete use cases (where it pays for itself)
Use case 1 — Stop two agents editing the same file
Scenario: Session Alpha is mid-refactor on src/auth/session.ts. Session Beta starts a "fix login flakiness" task and opens the same file.
Without messaging: Both edit. You merge by hand. Or the edit-lock fires late and one agent burns a turn waiting.
With messaging + claims:
- Alpha declares a claim: "editing session.ts — rotating token refresh."
- Beta's SessionStart digest shows the live claim.
- A Read of that file can surface a read-warn that a peer is actively editing.
- Beta messages Alpha: "I'll take tests only — hold off on the cookie path."
Claims are advisory (they never hard-block). That is the point: they make duplicate work visible early, when a redirect is cheap.
Use case 2 — Shared-lib landing notice (broadcast)
Scenario: One session lands a breaking change in a shared package. Three other sessions are mid-feature in consumers.
Without messaging: Consumer agents keep building against old APIs for twenty minutes. You discover the mess at integration time.
With broadcast:
pc msg send broadcast "landing hurc-lib auth change in 5 min — expect a brief gap on consumers"Every session drains the message at its next turn boundary. Agents can park, rebase, or finish their current edit deliberately.
Use case 3 — Lock negotiation instead of blind wait
Scenario: File-coord edit locks prevent simultaneous writes. A blocked agent sits until TTL expiry.
With lock-request: the blocked session asks the holder for ETA or release. The one fully automatic safe reply: if the holder no longer holds the lock, it auto-acks "clear to proceed" with no model in the loop. You save wall-clock time without green-lighting concurrent writes to the same path.
Use case 4 — Parked worker woken by a peer (Power Claude wake actuator)
Scenario: A worker session finished a chunk and parked. The orchestrator session finishes a dependency and needs the worker to continue.
Without wake: the message waits in the inbox until a human reopens the tab.
With wake actuator (opt-in): Power Claude watches harness wake requests and re-invokes the parked Claude Code session. Safety rails include leader election (one window actuates), per-target cooldown, message-id dedup, chain-depth cap, and emergency-off. The resume prompt is a constant continue line — not the peer body as an instruction.
Default for wake is off until you enable it. Messaging itself can still deliver on the next natural turn.
Use case 5 — Split a large PR across domain sessions
Scenario: You run auth, API, and UI sessions in parallel against one monorepo.
With peers + claims:
- Each session claims its domain files with intent text.
- Cross-domain blockers become messages ("need UserDto field X before UI can bind").
- Broadcast "API contract frozen" when the API session is ready for consumers.
Humans still own architecture. Agents stop pretending they are alone on the machine.
Use case 6 — Overnight fleet hygiene
Scenario: Twelve overnight jobs. One hits a secrets gap. Others keep thrashing the same dead path.
With messaging: the blocked session broadcasts "missing DEPLOY_TOKEN — stop retrying deploy scripts." Peers park that workstream. You fix secrets once in the morning instead of reading twelve identical failure loops.
Use case 7 — Multi-repo machine (harness-wide bus)
The bus is machine-wide, not repo-scoped. A session in power-claude can notify a session in neural-llm.com that a docs link will break. That is rare in IDE tools that only know the open workspace.
Use case 8 — Human review without tab spam
Inbound messages are agent-to-agent by default. Power Claude can show a Messages panel on demand (and an opt-in toast). The design goal: coordination without yanking your focus every time two agents whisper.
Security posture (why this is not "agents controlling agents")
Any multi-agent bus is a trust boundary. The design assumes peers can be wrong.
| Layer | Behavior |
|---|---|
| Filesystem ACL | Bus root is 0700 own-uid — other OS users cannot write it |
| Origin | Ed25519 signatures bind the from field to the sender's key |
| Freshness | Nonce replay markers + TTL |
| Quarantine | Failed checks never enter model context |
| Framing | Verified bodies are FYI peer data, not instructions |
| Rate limits | Per-(from,to) burst caps |
How Power Claude fits (product vs harness)
| Layer | Role |
|---|---|
| hurc harness | Bus, crypto, claims, presence, deliver hooks, lock negotiation, wake requests; works for Claude, Grok, Codex, Cursor, Gemini when hooks are wired |
| Power Claude | pc msg … CLI, optional inbound Messages panel (IDE), optional wake actuator (parked tab resume), Session Explorer cues, settings |
Surfaces that already work (not IDE-only)
| Surface | Send | Receive into model context | Human UI |
|---|---|---|---|
| VS Code / code-server (Claude Code tab) | pc msg send, skills, panel Reply | Deliver hooks on SessionStart / next turn | Messages panel, opt-in toast |
| CLI / terminal Claude Code (or other harness clients) | pc msg send / harness msg.sh | Same deliver hooks — no editor required | pc msg inbox, pc msg peers |
| Parked session | peers can still address it | Inbox drains on resume | Optional wake actuator re-opens a tab (IDE; opt-in) |
Try messaging from the CLI once two sessions are live (editor tabs or terminal):
pc msg peers
pc msg whoami
pc msg send <other-session-id> "hold off on media/dashboard.js — shipping a table fix"
pc msg send broadcast "shared types changing — rebase before editing API clients"
pc msg inbox --peekSession IDs come from pc msg peers (or harness msg.sh peers). The product page messaging section walks the human-facing surfaces.
Scenarios at a glance
| Scenario | Pain without bus | With bus |
|---|---|---|
| Two sessions, one file | Merge conflict / rework | Claim + message + redirect |
| Shared-lib break | Cascading consumer failures | Broadcast freeze window |
| Lock contention | Blind TTL wait | ETA / release query |
| Parked worker | Human babysitting | Opt-in wake + inbox |
| Overnight fleet | Silent duplicate thrash | Broadcast stop / replan |
| Cross-repo machine | No channel | Machine-wide inbox |
| Reviewer noise | Constant tab stealing | On-demand panel, opt-in toast |
What this is not
- Not a replacement for code review or human architecture decisions
- Not automatic multi-agent consensus or swarm voting
- Not a cloud multi-tenant message product
- Not "bypass rate limits by chatting" — rate limits and profile handling are separate Power Claude surfaces
- Not permission to treat peer text as system prompts
Frequently asked questions
Do other Claude Code tools already do this?
Parent–child messaging inside one product's "team" mode is common. A machine-wide, signed bus between independently started top-level sessions, with claims and lock negotiation, is not. Most people still coordinate fleets with humans and hope.
Does messaging leave my machine?
Local plane (this article): no. The bus is local files under your home harness state directory. There is no Neural-LLM cloud hop for message bodies.
Opt-in remote plane: you can pair another machine you control (volume or SSH). That is a separate, default-OFF feature — see Link AI coding sessions across machines. Remote still does not route bodies through Neural-LLM servers.
Can a malicious session forge another session's identity?
Not via the bus protocol: messages are Ed25519-signed over a canonical subset that includes from. Same-uid compromise of your user account is out of scope for any local tool — that is an OS boundary, not a bus bug.
Will agents start infinite message loops?
There are rate caps, TTL, loop-aware wake depth limits on the Power Claude actuator, and soft/hard TTLs on claims. Wake is opt-in and fail-closed. You can disable messaging per consumer config.
Does this work if I only have one session open?
Yes, but you will not feel it. Cost is near-zero when inboxes are empty (default-on, silent). The value shows up when you run concurrent sessions.
Does messaging work from the CLI, or only inside VS Code?
CLI and IDE both work. The bus is file-based and client-agnostic. pc msg send / peers / inbox run in a terminal; active sessions receive via harness deliver hooks whether they are editor tabs or CLI. Only optional human chrome (Messages panel, toast) and the wake actuator for parked tabs are IDE features.
How do I try it today?
Install Power Claude (or a harness-wired client), run two coding-agent sessions (two IDE tabs, two CLIs, or one of each), list peers with pc msg peers, and pc msg send a short coordination note. Enable the wake actuator only after you are comfortable with parked sessions being re-opened. Details: Power Claude product page and the 14-day Premium Trial.
Closing
Parallel agents without a coordination channel are just parallel sources of merge pain. Rate-limit pooling and session recovery keep individual loops alive; inter-session messaging is what keeps a fleet coherent.
If you already open more than one Claude Code window on a real codebase, this is the layer that turns "hope they don't collide" into "they can actually talk."
Start the Premium Trial · Download Power Claude · Read the messaging feature overview
Related reading
- Link AI coding sessions across machines — opt-in remote pair / observe notes
- Agentic coding agent fleets in 2026 — why fleets change cost and reliability
- Recovering Claude Code sessions mid-task — when a single session dies
- Claude Code should I continue prompts — polite stops vs real blockers