Proposal: experimental local cross-session messaging via UDS

Open 💬 2 comments Opened Apr 1, 2026 by panchen451161722
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

CLI

What feature would you like to see?

Background

Currently, Codex sessions are isolated. Multiple CLI instances on the same machine cannot communicate or coordinate.

---

Proposal

Introduce an experimental, local-only cross-session messaging mechanism using Unix Domain Sockets (UDS).

Goal:

One session can send a text message to another, and the receiving agent sees it directly in its conversation context.

---

Scope (Stage 0)

Keep the first version minimal:

  • Local machine only (UDS)
  • Plain text messages only
  • No persistence
  • Top-level sessions only
  • No file transfer or structured payloads

---

User-facing behavior

Two new tools:

  • list_sessions — discover other sessions
  • send_session_message(target, message) — send a message

---

Behavior

When a message is received:

  • It is injected into the target session’s conversation context
  • The agent sees it as a normal input on the next turn and can respond

Questions

Would appreciate feedback on:

  1. Is injecting messages into the conversation context acceptable?
  2. Should this reuse existing InterAgentCommunication, or be separate?
  3. Is UDS a reasonable transport for a first step?

---

Next step

If this direction makes sense, I can follow up with a small, feature-flagged PR implementing Stage 0.

Additional information

_No response_

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 4 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • ##15355
  • ##15299
  • ##15504

Powered by Codex Action

prassanna-ravishankar · 2 months ago

the list_sessions + send_session_message(target, message) shape you propose is almost exactly the surface i landed on in repowire, where its list_peers + notify_peer(target, message) over a local daemon.

two things i'd flag from building it that are worth deciding up front:

  • address by a stable id, not a display name. multiple codex sessions in the same dir collide on any path/name-based key, so routing has to canonicalise underneath or you get intermittent misroutes
  • give the message an explicit ack so the sender can tell delivered vs the receiver-was-busy case, otherwise it's fire-and-forget and the failure mode is invisible

UDS vs a small daemon is mostly a taste call, the harder parts are identity and delivery semantics rather than the socket. happy to share what bit me if useful.