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.
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
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 the IDE. Most day-to-day Claude Code / Cursor / Codex users never wire that into their real editor sessions.
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: IDE-native, multi-session, same-machine, coding-agent fleet coordination — not a research multi-agent framework and not a chat product.
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."
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.
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 |
| Power Claude | pc msg send, inbound Messages panel, optional wake actuator, Session Explorer cues, settings |
Try messaging from the CLI once two sessions are live:
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"Session IDs come from peers listing. 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?
No. The bus is local files under your home harness state directory. There is no Neural-LLM cloud hop for message bodies.
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.
How do I try it today?
Install Power Claude, run two Claude Code sessions, list 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
- 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