I’m writing as a heavy user of both Codex and Claude Code in a multi-agent engineering workflow. Codex is already a world-class coding model. Its reasoning, code review quality, and implementation discipline are strong enough that I want it deeply integrated into my agent teams. But there is one missing runtime capability that makes Codex significantly harder to use than Claude Code for coordinated multi-agent work: Codex needs a true event-driven interaction path for agent-to-agent communication.
In our workflow, multiple agents collaborate through peer messaging systems such as model-peers and claude-peers. These are used for real engineering coordination: handing off code review findings, requesting compile proof, blocking unsafe commits, routing architecture decisions, and synchronizing work across repositories. When this works well, agents can coordinate almost like a team of engineers: one agent sends a message, another agent receives it, reasons over it, acknowledges it, and responds with a decision or next action.
Claude Code handles this very well. Peer messages can be injected into the agent’s active cognitive path, and the agent responds quickly. The result is that Claude agents feel “present” in the collaboration loop. They do not require external heartbeat scripts, cron jobs, or manual polling to notice important messages.
Codex, by contrast, currently behaves more like a turn-bound request/response system. It only reliably sees peer messages at explicit turn boundaries, tool hooks, stop hooks, or when instructed to call a polling tool. If Codex is idle, stopped, or busy in a long-running task, peer messages can sit unacknowledged for hours. We have tried workarounds: heartbeats, cron polling, hook scripts, stop-time inbox checks, and automated “receipt” messages. These help detect that messages exist, but they do not solve the real problem: they do not bring the message into Codex’s reasoning loop and cause Codex to produce a substantive response.
That distinction matters. A heartbeat can say “message detected,” but it cannot make Codex think. Worse, automatic receipts can create false confidence: other agents may believe Codex has consumed a message when the actual Codex cognitive path has not read or acted on it.
The missing feature is not better model intelligence. The model is excellent. The missing feature is runtime-level event delivery.
The ideal Codex capability would look like this:
-
Codex can subscribe to external agent-message sources, including MCP-based peer systems.
-
When a high-priority message arrives, Codex can be woken or interrupted safely.
-
The message is injected into the active context as a first-class event, not as a best-effort hook artifact.
-
Codex is required to acknowledge, defer, or respond before continuing unrelated work.
-
The system distinguishes between “detected by automation” and “read/reasoned over by Codex.”
-
Priority, thread ID, sender, expiry, and reply requirements are preserved.
-
Users can configure safety policies: which sources can interrupt, which messages require confirmation, and which can be deferred.
-
Long-running tasks can checkpoint, receive the message, respond, and then resume.
In other words: Codex needs an event-driven agent communication path, not just polling.
This would make Codex much more attractive to engineering teams that already use multiple AI tools together. Many advanced users want to use Codex and Claude Code side by side. Codex is excellent for rigorous coding, repository work, and technical review. Claude Code currently has an advantage in live multi-agent coordination because its runtime is more responsive to peer events. If Codex added native event-driven peer communication, it would become much easier to use as a reliable member of autonomous engineering teams.
A practical implementation could start with MCP:
-
Add an MCP event subscription mechanism for Codex sessions.
-
Allow configured tools or servers to emit “attention required” events.
-
Surface those events in the model context immediately or at safe interruption points.
-
Provide a built-in ack/defer/reply workflow.
-
Expose message state so other agents know whether Codex merely received an event or actually reasoned over it.
-
Support priority classes: informational, normal, blocking, urgent.
-
Allow repo-level policies so teams can enforce “no implementation while high-priority peer messages are unacknowledged.”
This would remove the need for fragile cron and heartbeat workarounds. More importantly, it would make Codex feel like an active collaborator rather than a powerful model that must be manually woken up to participate in coordination.
Codex is already strong enough to be a core engineering agent. Giving it a true event-driven interaction path would make it much more reliable in multi-agent workflows and much more compelling for engineers who want to combine the strengths of Codex, ChatGPT, Claude Code, and custom MCP systems.
This is the feature I most want to see in a future Codex release: first-class agent-to-agent communication with real cognitive interruption, acknowledgement, and response semantics.