Feature request Task-board and cross-thread context routing for Codex App

[philosophicalsmith-beep]

I really enjoy using Codex App, and I would love to see it become even better for long-running agent work.

My current workflow is that I use multiple Codex App threads as durable tasks. In practice, each thread already behaves like a long-lived work item: it has its own context, history, project or worktree state, terminal output, generated artifacts, and follow-up conversation.

The missing layer is a lightweight task board and cross-thread handoff system.

Today, many users already use multiple Codex threads as a set of long-lived agents:

• one thread writes code, another reviews it;
• one thread drafts an article, another fact-checks it;
• one thread researches, another synthesizes;
• one thread acts as a project coordinator;
• one thread explores an idea while another challenges the assumptions.

This works well conceptually, but in practice these threads are still isolated. When I want one thread to review another thread's work, or when I want a coordinator thread to summarize and route work across several threads, I still need to manually copy and paste context.

Desired capabilities:

• A board/list view for Codex threads, with statuses such as TODO, DOING, REVIEW, BLOCKED, and DONE.
• Tags or labels for threads, such as writer, reviewer, researcher, frontend, backend, article, investigation, and review.
• A reliable way for one thread to reference or summarize another thread.
• A dispatcher/controller thread that can list active threads, inspect summaries, send follow-up prompts, and aggregate progress.
• Thread-to-thread handoff, for example: "send this result to thread X for review" or "ask thread Y to critique this plan."
• A shared cross-thread context index, with explicit opt-in privacy controls and project boundaries.
• Optional dashboard support for thread automations, recurring check-ins, and long-running review loops.

Codex App already has many of the necessary primitives: durable threads, worktrees, automations, background threads, thread search, pinned/archived state, and app-server primitives. What seems missing is a first-class UI and protocol for coordinating those threads.

This would make Codex App feel less like a list of isolated chats and more like a local agent workspace: a lightweight Multica-like task board, but native to Codex threads.

Key request:

Please consider adding a Codex-native task board and cross-thread context/handoff system.

[milan-seitler]

I would also utilize an option for a thread to be able to communicate with other threads. Right now, as a workaround, you can define persistent subagent sessions in Codex CLI and call them from the main thread. I use it for my team of subagents but more elegant solution would be nice.

[zhaoyeyu]

I have been working on an external version of part of this problem in TaskState Vault.

It does not coordinate Codex threads directly yet, so it is not a replacement for the native task board and thread-routing model you describe. What it does provide today is a tool-neutral project state model outside the conversations: stable project intent, a dependency-aware task graph, execution queue, blockers, current task state, next actions, run records, evidence/artifacts/errors, layered indexes, and a read-only local UI.

I am using it myself because I wanted project state to survive thread boundaries without making chat history the source of truth. Your proposal highlights the missing integration clearly: associating TaskState Vault tasks and runs with Codex thread references and turning explicit handoffs into first-class records.

If you are interested, I would value your opinion on whether this external state model is useful alongside the native UI you propose, and what minimum thread/handoff fields would make the two approaches fit together.