Shared workspace/message bus for Codex subagents

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

What variant of Codex are you using?

Codex CLI

What feature would you like to see?

I would like Codex subagents to have an optional shared coordination scope where they can exchange short structured messages, status updates, findings, and handoff notes during a multi-agent workflow.

Current subagent workflows are useful for parallel work, but coordination is mostly parent-mediated: subagents run in separate agent threads and the parent agent waits for results, then consolidates them. This works for independent tasks, but becomes limiting when multiple specialized agents need to coordinate around a shared investigation or implementation plan.

Current behavior

Codex can spawn subagents in parallel and collect their results into one consolidated response. The user can inspect or steer agent threads via /agent.

However, there does not appear to be a first-class shared thread, shared inbox, or common subagent scope where subagents can communicate with each other directly or publish structured intermediate findings visible to other subagents.

Users currently have to emulate shared state manually through files such as:

.agent-work/<task-id>/
  board.md
  decisions.md
  audit.md
  implementation.md
  test.md

That workaround is usable, but it is not first-class, has no built-in locking or ownership semantics, and can cause coordination issues when multiple agents write concurrently.

Proposed feature

Add an optional shared communication scope for subagent workflows.

Possible config shape:

[agents]
max_threads = 5
max_depth = 1
shared_workspace = true
shared_workspace_mode = "append-only" # or "parent-mediated"

[agents.shared_workspace]
path = ".codex/shared-agent-work"
visibility = "workflow" # workflow | project | session

Or a more explicit model:

[subagents.shared_scope]
enabled = true
kind = "message_bus" # message_bus | files | hybrid
visibility = "workflow"
write_policy = "append-only"

Desired behavior

When a multi-agent workflow starts, Codex creates a task-local shared scope, for example:

shared_scope:
  - board
  - agent status events
  - findings
  - handoff notes
  - decisions accepted by parent

Subagents should be able to:

  • append status updates
  • append findings
  • read findings from other subagents
  • address messages to another agent or to the parent
  • publish final handoff notes

The parent/orchestrator should be able to:

  • create the shared scope
  • merge findings into accepted decisions
  • resolve conflicts
  • decide what enters the main conversation context
  • summarize shared activity to the user

Example workflow

User prompt:

Use audit, etls, and mcpm in parallel.
They should coordinate through a shared workspace.
audit checks risks, etls checks implementation, mcpm checks MCP/server impact.
Wait for all of them and return a consolidated plan.

Expected behavior:

main thread
  ├─ creates shared scope for this workflow
  ├─ spawns audit
  ├─ spawns etls
  ├─ spawns mcpm
  ├─ agents publish findings/status to shared scope
  ├─ agents can read each other’s published findings
  └─ parent consolidates final result

Why this matters

For real project workflows, subagents are often not completely independent. They may need to coordinate on:

  • shared assumptions
  • intermediate discoveries
  • ownership of files or modules
  • whether a finding invalidates another agent’s plan
  • conflict resolution before final implementation
  • long-running investigation state

Without a first-class shared scope, the parent must manually relay information between agents, or users must create ad-hoc filesystem protocols.

Safety and conflict controls

This feature should not mean unrestricted shared editing.

A safe MVP could be:

  • append-only message bus
  • parent-owned decisions
  • per-agent namespaced notes
  • no direct overwrite of another agent’s notes
  • optional visibility in TUI
  • optional /agent shared or /agent board view
  • parent decides what enters main conversation context

For write-heavy workflows, Codex could explicitly recommend separate worktrees or per-agent file ownership to avoid conflicts.

Relationship to existing work

This is related to #12047, which proposes a broader multi-agent TUI overhaul with named agents, shared team inbox, async orchestration, and @mention messaging.

This issue is intended as a narrower MVP-focused request: provide a first-class shared coordination scope/message bus for subagents, even without the full team/TUI model.

Desired outcome

  • A multi-subagent workflow can create a task-local shared scope.
  • Each subagent can append structured messages/findings/status updates.
  • Subagents can read shared-scope entries from other subagents.
  • The parent agent can summarize or promote entries into the main response.
  • The user can inspect the shared scope from the CLI/TUI.
  • The feature is opt-in and backward-compatible.
  • Shared writes are safe by default, preferably append-only or parent-mediated.

Additional information

_No response_

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

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

  • #20312
  • #19398

Powered by Codex Action

davidmonreal · 1 month ago

I arrived at a very similar need while coordinating multiple Codex tasks in the same repository. My approach is based on two complementary pieces:

  • TEAMWORK.md: the repository’s shared working agreement for agents.
  • A coordination artifact: the live view of what is currently happening across tasks.

TEAMWORK.md defines how agents behave as a team: before editing, check ongoing work; declare the scope of the task; avoid overlapping changes; communicate dependencies or blockers; use clear branch/worktree ownership; run the expected quality gates; and make handoffs and integration explicit.

The coordination artifact is the dynamic counterpart. It tracks active tasks, their owner, status, affected areas, dependencies, decisions, and pending handoffs. In other words: it gives each agent awareness of the rest of the team.

This distinction matters. A shared workspace is not only a place to write notes; it is a shared operating model. TEAMWORK.md contains the durable rules, while the coordination artifact represents the team’s current state.

It is essentially the machine equivalent of how human engineering teams work: we have dailies to know where everyone is, task boards to make work visible, ownership to avoid stepping on each other’s changes, quality gates to validate the output, and a controlled merge process to integrate work. In real time.

leadingproblemsolver · 20 days ago

The TEAMWORK.md + live coordination artifact split makes sense. I would make one additional constraint explicit: the live artifact should be a projection, not the source of truth itself.

A mutable board that every subagent rewrites will eventually create the same failure mode as shared chat context: last-writer-wins state, lost blockers, and no way to tell why a status changed.

I would keep append-only coordination events underneath it:

{
  "event_id": "evt_...",
  "task_id": "auth-refresh",
  "agent_id": "reviewer-2",
  "kind": "blocker_observed",
  "payload": {
    "text": "fixture still assumes old issuer",
    "source": "tests/auth/test_jwt.py",
    "line": 83,
    "source_hash": "..."
  },
  "observed_at": "..."
}

Then derive the compact shared view:

append-only coordination events
        ↓
reconcile by task / agent / source version
        ↓
current task board + blockers + handoffs + ownership

That gives a few useful invariants for multi-agent work:

  • agents can append observations without clobbering another agent's state;
  • done can be traced to the event/evidence that justified it;
  • ownership changes retain history instead of overwriting the prior owner;
  • stale blockers can be invalidated when their source changes;
  • a reconnecting agent can request only events after cursor N rather than rereading the entire shared workspace;
  • the UI can show a compact board while drill-down still reaches the original source/event.

This also makes concurrency less scary: the coordination bus does not need globally consistent free-form text, only stable event IDs plus per-task ordering/reconciliation rules.

I maintain a small local-first implementation of the evidence/projection side of this pattern: deterministic records for decisions/blockers/actions with source path + line/content-hash provenance in SQLite, plus source-linked context packs: https://github.com/leadingproblemsolver/living-context-engine

It is not a multi-agent message bus, but it demonstrates the useful boundary here: shared state is derived from traceable observations rather than becoming another mutable blob agents have to trust.