Proposal: Open, Community-Extensible Taskboard and Agent Orchestration for Codex

[zc52406]

Summary

I would like to propose an open, community-extensible task coordination layer for Codex.

The goal is to support workflows commonly found in issue trackers and managed-agent platforms:

• Projects and issue boards
• Priorities, dependencies, labels, and assignees
• Assigning issues to Codex agents
• Binding issues to repositories, branches, worktrees, and Codex threads
• Tracking queued, running, blocked, awaiting-approval, review, failed, and completed states
• Scheduling recurring engineering work
• Reviewing progress, approvals, logs, diffs, and results from one place

I am not asking OpenAI to build and maintain a complete project-management product.

A good outcome could be either:

1. An open-source reference implementation maintained with the community; or
2. Stable, permission-scoped extension APIs that allow individual contributors to build this as a shareable Codex plugin.

Why existing capabilities are not yet sufficient

Codex already provides valuable building blocks:

• Skills and Plugins
• MCP connectors and optional UI
• codex app-server with JSON-RPC lifecycle events
• Codex automations and recurring tasks

Community projects such as Threadlines demonstrate that App Server can power a complete independent Codex workspace.

However, the documented extension surfaces do not currently appear to provide a complete path for implementing this workflow inside Codex Desktop:

• No documented persistent sidebar or panel contribution point
• No documented way to associate an external record with a native Desktop thread and open it by threadId
• No documented bridge to the same thread store and lifecycle used by Codex Desktop
• No documented plugin API for managing Codex automations programmatically
• No reference plugin combining custom UI, native thread navigation, approvals, and lifecycle events

Proposed extension points

UI contributions

• ui.sidebar
• ui.panel
• Sandboxed plugin WebViews
• Persistent plugin navigation destinations
• Theme tokens and standard Codex UI components

Thread and task integration

• threads.read
• threads.create
• threads.open
• threads.linkExternalRecord
• threads.subscribeLifecycle

Events should cover:

• queued
• running
• waiting for approval
• waiting for user input
• blocked
• failed
• completed
• cancelled

Project and worktree context

• projects.read
• repositories.read
• branches.read
• worktrees.read
• Supported association of a thread with a repository, branch, or worktree

Approvals

• Subscribe to approval requests
• Present approval details in a sandboxed plugin UI
• Submit approval decisions through scoped APIs
• Preserve Codex’s existing confirmation and security policies

Automations

• automations.read
• automations.create
• automations.update
• automations.pause
• automations.delete

Navigation

• A documented deep-link or API for opening a native Codex thread, project, diff, or approval request

Security model

Each capability should require explicit permissions.

Plugins should not receive unrestricted access to threads, files, commands, or approvals. Workspace administrators should be able to limit installation, data access, execution, and write actions.

Sensitive actions should continue to require user confirmation.

Community contribution proposal

Individual contributors could build and maintain the taskboard, issue model, database, synchronization layer, and UI.

OpenAI would only need to provide and stabilize the integration contracts that cannot be implemented outside Codex:

• Desktop UI contribution points
• Native thread navigation
• Thread lifecycle events
• Project/worktree context
• Approval APIs
• Automation management APIs

An official sample plugin combining these capabilities would make community development substantially easier.

I would be willing to contribute implementation work, testing, documentation, Chinese localization, and feedback from a working taskboard prototype.

Related discussions and issues

• General Desktop plugin system: I hope the Codex app can support a plugin system like VSCode’s. #36649
• Stable App Server and thread steering: [Feature Request] First-class support for Headless Thread Steering & Stable App-Server API for external workflow controllers #36694
• Independent App Server workspace example: Threadlines: an open-source desktop workspace for Codex and Claude Code #36346

This proposal connects those capabilities through a concrete, community-buildable workflow rather than requesting a duplicate implementation.

[bobleer]

The extension points look about right. The one thing I would not make primitive is threads.linkExternalRecord as a permanent 1:1 mapping.

A board item can be retried, forked, handed to a subagent, or resumed after a runtime restart. The old thread is still useful audit history. In BitFun we ended up needing a separate binding record: external task id, runtime session/thread id, attempt, repo/worktree identity, controller lease, and last event cursor.

That changes approvals too: bind an approval to the attempt plus an action digest, not just the board item. Otherwise a stale panel can approve a newer retry by accident.

If I had to stage this, I would ship native thread navigation, resumable lifecycle events, and scoped approvals before sidebar UI. A community UI can build around those; it cannot safely reconstruct them. We wrote up the process boundary here: https://github.com/GCWing/BitFun/blob/main/docs/architecture/agent-runtime-deployment-design.md