Feature request: project teams with persistent workers, lanes, and shared agent channels

What variant of Codex are you using?

Codex App and CLI, with the same project model ideally available across the IDE extension and Web/ChatGPT surfaces.

What feature would you like to see?

First-class project teams, lanes, and shared agent channels

Summary

Add an organization-style collaboration layer to Codex projects so users can create persistent workers, lanes, and shared chat channels instead of coordinating entirely through isolated threads.

The current multi-agent model is useful for delegating individual tasks, but it does not provide a durable team workspace where agents can communicate, coordinate, delegate, and work together in shared channels.

Problem

Today, each Codex agent primarily operates in its own thread. This creates several coordination problems:

• Agents cannot naturally participate in a shared group conversation.
• Users must manually relay information between threads.
• Worker identity, role, membership, and assignment are not durable organizational concepts.
• There is no clear way to organize agents into lanes such as research, engineering, testing, documentation, or integration.
• Agents cannot easily discover relevant updates from other workers in the same lane.
• Managers or supervisor agents cannot maintain a persistent view across multiple work areas.
• Status updates, handoffs, blockers, and decisions are scattered across separate threads.

This makes Codex effective for parallel task delegation, but much less effective for persistent agent teams or organization-style workflows.

Proposed feature

Allow each project to contain teams, lanes, and channels.

Example:

Project
├── Coordination
├── Research
├── Engineering
│   ├── Backend
│   └── Frontend
├── Testing
└── Documentation

Each channel would have:

• Persistent message history
• Worker subscriptions
• Membership and permission controls
• Mentions and direct addressing
• Status updates and handoffs
• Configurable notification or wake behavior
• Support for human and agent participants

A worker could belong to one lane, subscribe to several channels, or act as a cross-lane manager or supervisor.

Persistent workers and private execution threads

A worker should be a durable project-level identity, separate from its current execution thread or runtime session.

Each worker would have:

• Stable identity
• Role or mandate
• Current lane assignments
• Channel memberships
• Status and checkpoints
• A private Codex execution thread or session
• The ability to pause, resume, move, or reconnect to its work

The channel should be a shared coordination stream, not one giant shared model context. Each worker should retain its own private thread history while receiving bounded, relevant channel messages, decisions, blockers, and handoffs.

This preserves context isolation, privacy, and predictable token usage while still allowing agents to work as a team.

Conversation modes

The system should support several forms of communication.

Direct message

A private conversation between a user and one worker, or between two workers.

Selected fanout

A user or agent sends a message to several selected workers.

Possible reply modes:

• Private replies to the sender
• Shared discussion where all selected participants see every response
• Linked private and shared conversations, where a participant can explicitly publish a reply or summary

Shared channel

All permitted members can see and respond to messages in the channel.

Agents should be able to:

• Post updates
• Reply to each other
• Mention specific workers
• Request help
• Delegate work
• Create handoffs
• Publish decisions or summaries
• Invite eligible workers
• Ask supervisors for approval

Mentions should control attention or wake behavior, but should not automatically grant visibility or authority.

Lane and membership management

With appropriate permissions, users and supervisor agents should be able to:

• Create, rename, archive, or restore lanes
• Create channels within lanes
• Add or remove workers
• Invite workers to channels
• Allow workers to request or self-join channels
• Move workers between assignments
• Create new worker roles
• Define lane-specific instructions and responsibilities
• Set cross-lane communication boundaries
• Configure which workers are actively woken by channel messages

Channel membership and work authority should remain separate. Joining a channel should not automatically grant access to private threads, repositories, tools, or lane authority.

How this differs from Slack or Buzz

This is not intended to be a generic chat application or a replacement for Slack.

Slack is primarily a human communication system. Bots and agents can participate, but channels do not normally represent durable workers with private execution context, task authority, lane assignments, checkpoints, or resumable work sessions.

Buzz is closer because it provides agent-channel routing, mentions, subscriptions, and ACP-based interaction. However, the proposed feature treats channels as part of a persistent execution and organizational model, not only as message-routing surfaces.

The important additional concepts are:

• Persistent worker identities separate from individual threads or processes
• Durable lane assignments, roles, mandates, and permissions
• Per-worker private execution threads connected to shared channels
• Bounded context delivery from channels into each worker’s private context
• Worker-to-worker delegation, handoffs, checkpoints, and status
• Persistent session attachment and recovery across restarts
• Managers and supervisor agents with cross-lane visibility
• Explicit separation between channel membership, message visibility, attention, and work authority
• Runtime flexibility for the Codex app, CLI, App Server, local harnesses, or custom Codex builds

Slack or Buzz could still be used as external communication bridges. The requested Codex feature would be an execution-aware project organization layer: channels are connected to active workers, work boundaries, and runtime sessions rather than being only places where messages are exchanged.

A useful distinction is:

Slack: human communication
Buzz: agent message routing
Proposed Codex feature: persistent agent organization and execution coordination

Example workflow

A project might contain:

• #coordination
• #research
• #backend
• #frontend
• #testing
• #documentation

A manager worker subscribes to all channels. Engineering workers subscribe to their respective implementation lanes. A testing worker subscribes to testing and integration. A human can post in #coordination, tag several workers, and receive either private responses or a shared discussion.

A backend worker can then post directly in #backend, mention the testing worker, and create a handoff to #testing. The manager can observe status and blockers without needing access to every worker’s private reasoning or full thread history.

Runtime flexibility

The coordination layer should remain independent of the underlying Codex runtime.

It should support:

• The standard Codex app or CLI
• Codex App Server integrations
• Local Codex harnesses
• Custom Codex builds
• Other compatible agent runtimes in the future

The project/channel layer should manage workers, memberships, messages, permissions, and context delivery, while the worker runtime continues to own the agent’s private execution session. The feature should not depend on one specific Codex binary or runtime configuration.

Suggested MVP

A minimal first version could include:

1. Project-level teams and channels
2. Persistent worker identities
3. Worker subscription and membership management
4. Shared channel history
5. Human-to-worker and worker-to-worker messaging
6. Direct messages and selected fanout
7. Mentions and configurable wake behavior
8. Worker status and checkpoint updates
9. Private execution threads per worker
10. Basic permissions for managers, workers, and project owners
11. Persistence across app restarts

This would complement the existing thread model rather than replace it:

• Threads remain the private execution surface.
• Channels become the organizational coordination surface.
• Workers become the durable identity connecting the two.

Why this would be valuable

This feature would make Codex substantially better for:

• Long-running software projects
• Parallel engineering teams
• Research and analysis workflows
• Supervisor and manager agents
• Multi-repository projects
• Human-agent collaboration
• Persistent autonomous or semi-autonomous workers
• Teams using custom Codex runtimes or local harnesses

It would also provide a more natural foundation for agent orchestration than repeatedly creating isolated threads and manually relaying information between them.

Non-goals for the initial version

The initial implementation should not try to become:

• A replacement for GitHub
• A replacement for Slack or Discord
• One giant shared model context
• An unbounded autonomous-agent network
• A mechanism for consuming another user’s agent quota
• A generic social network

The initial goal is narrower: make Codex projects support persistent workers that can communicate, coordinate, and execute work within explicit lanes and shared channels.

Related issues

This request is related to, but distinct from:

• #21998, which focuses on reusable multi-agent orchestration workflows and work graphs.
• #29264, which discusses broader multi-agent and tool integration.
• #35586, which focuses more broadly on a human-agent social network.

This request focuses specifically on the missing project-level organizational layer for persistent workers, lanes, memberships, shared channels, and execution-aware coordination.

Additional information

I am exploring this model through a custom local harness because the current thread-to-thread model requires manual bulletin-style coordination between workers. A native Codex implementation would provide a much simpler and more coherent experience while preserving each worker’s private execution context.