Codex Desktop: first-class coordinator project role for cross-repository workflows

What variant of Codex are you using?

Codex desktop app

What feature would you like to see?

Summary

Add a first-class Coordinator role or preset for Codex Desktop projects. A coordinator project should be intended for investigation, planning, and cross-project task management, while implementation occurs in dedicated repository projects.

Problem

For a product composed of multiple repositories, users may want:

• one long-lived project used to investigate production issues and coordinate work;
• separate saved projects for each repository, where implementation happens.

Today the coordinator is still treated like an implementation project. It can edit its workspace, create Git state, and drift into implementing fixes itself. Project-local .codex/config.toml and AGENTS.md are partial workarounds, but:

• project config is bound to a filesystem root, not the saved-project identity;
• two saved projects may intentionally point to the same checkout for different roles;
• making one saved project read-only can therefore also affect the implementation project sharing that path;
• instructions are advisory and do not define a visible, enforced product role;
• routing implementation into another saved project is not presented as the default workflow.

Proposed behavior

Allow a saved project to be marked Coordinator in Desktop project settings.

A coordinator project would:

• default local filesystem access to read-only;
• keep browsing, search, MCP reads, and code inspection available;
• expose task creation/list/read/wait/message/handoff primitives consistently;
• let the user select permitted destination projects;
• create implementation tasks directly in those destination projects and their worktrees;
• keep source edits, commits, pushes, and PRs in the owning repository task;
• show a visible Coordinator badge or mode in the sidebar and composer;
• record an audit trail linking coordinator decisions to implementation tasks;
• allow explicit per-action escalation if the user intentionally wants the coordinator to write.

Potential UI:

Project settings → Role

• Standard
• Coordinator

Coordinator settings could include:

• allowed destination projects;
• default task environment (worktree or local);
• default permissions for implementation tasks;
• whether external write actions require approval.

Example workflow

1. The coordinator investigates a Bugsnag error.
2. It identifies the owning package or repository.
3. It creates a task in that repository's saved project.
4. The repository task implements, tests, and opens a PR.
5. The coordinator waits for and reviews the result, then coordinates dependent changes in other repositories.
6. The coordinator itself never mutates source or Git state unless explicitly overridden.

Why existing mechanisms are insufficient

• AGENTS.md: advisory, not a visible or enforced saved-project role.
• Project-local permission profiles: tied to the checkout path and can collide when multiple saved projects share one root. Desktop also has open issues around applying them reliably.
• Subagents: scoped to a task, not durable repository-owned saved projects and worktrees.
• Cross-task orchestration: necessary plumbing, but does not define a coordinator project's behavior, permission posture, destination allowlist, or UI.

Related but distinct

• #14923 requests explicit cross-task orchestration primitives. This request builds on that plumbing by defining a project-level coordinator role and workflow.
• #36575 requests project-level instructions. Instructions are part of the solution, but this also needs enforced permission defaults, destination-project routing, and visible role semantics.
• #32863 demonstrates coordinator and implementation role confusion in a long-running workflow. This feature would make that distinction explicit.
• #22553 concerns Desktop applying project-local permission profiles. This request avoids relying solely on path-scoped configuration for saved-project identity.

Acceptance criteria

• A user can mark a saved project as Coordinator.
• Coordinator mode is visible in the UI and preserved across tasks.
• The coordinator defaults to read-only local filesystem access.
• It can inspect and manage tasks in explicitly allowed saved projects.
• Implementation task creation targets the selected repository project and correct worktree.
• The coordinator cannot silently edit or commit in its own workspace under default settings.
• The user can deliberately override the role for a specific action with visible confirmation.
• Cross-task actions and implementation ownership are auditable.

Additional information

This supports multi-repository products where one long-lived task owns incident triage and planning while repository-specific tasks own implementation.