• 

  Settings Page

• 

  Cue Board

Codex Dirigent

Inspiration

Codex can implement a focused task remarkably quickly, but directing several tasks at once creates a different problem: changes can collide, context can get lost, and a fast result can reach the main branch before anyone has reviewed it. We were inspired by the original Dirigent workflow and reimagined it as a smaller, Codex-native macOS application. The goal was to make parallel agentic coding feel less like supervising terminals and more like conducting a clear, reviewable process.

What it does

Codex Dirigent is a native "control room" for Codex CLI. A developer opens a local Git repository, browses its files read-only, and creates repository-, file-, or line-range Cues. Any number of Cues can wait in the Inbox, and Run Inbox starts them concurrently in separate Git worktrees.

Each Cue moves through Inbox, Run, Review, Done, and Archive. Codex progress is streamed into the app, follow-up instructions continue the same task, and the resulting diff must be reviewed explicitly. Acceptance applies only to the exact diff that was inspected: if the worktree changes afterward, approval is invalidated. Only then can Codex Dirigent commit the Cue and merge it into a clean main branch. Conflicts are detected before main is modified.

How we built it

We built the application and UI in Rust using eframe and egui, with macOS as the first-class target. Codex CLI is the only AI backend and Git is the version-control backend, so the core can model the real workflow directly instead of routing everything through generic provider abstractions.

Codex Dirigent launches codex exec --json, sends prompts over standard input, and converts the JSON event stream into typed progress events for the UI. Each running Cue receives a dedicated branch and linked worktree. Git remains the source of truth for status, diffs, commits, merge preflights, and recovery.

Settings and the Cue Board are stored as small, versioned JSON documents using atomic replacement. We persist user intent and recovery metadata, but never secrets, generated diffs, subprocess state, or approval fingerprints. Codex with GPT-5.6 also helped us implement and test this durable restart behavior, which we then reviewed and integrated through the same Git workflow the app is designed to enforce.

Challenges we ran into

The hardest challenge was making concurrency safe without making the product feel complicated. Worktrees isolate file changes, but merging still requires a clean primary checkout, conflict prediction, careful branch ownership, and a clear recovery path when the application restarts halfway through a Cue.

We also had to keep long-running Codex processes and streamed output from blocking the native UI. Stale worker messages cannot be allowed to overwrite a newer run, cancellation must be predictable, and failures need to return a Cue to a safe actionable state.

Persistence introduced another subtle boundary: enough information must survive a restart to recover the board and conversations, while an old saved record must never fabricate a reviewable worktree or silently preserve an approval that is no longer valid. Finally, producing a universal Intel and Apple Silicon application required Developer ID signing, hardened runtime, notarization, stapling, and release verification in addition to normal Rust testing.

Accomplishments that we're proud of

We delivered the complete path from an idea in the Inbox to a reviewed commit on main: unlimited queued Cues, concurrent worktree execution, streamed Codex progress, follow-up refinement, exact-diff acceptance, merge preflight, and restart recovery.

The result is intentionally focused. There is no provider selector, hosted model integration, remote workspace layer, or hidden automatic commit path. Safety rules are represented in the domain model and covered by unit and end-to-end workflow tests, including concurrent Cues that merge cleanly and conflicting Cues that leave main untouched.

We are also proud that Codex Dirigent is more than a prototype: it's a tool which can build it self, but is very useful to build other projects.

What we learned

Isolation is necessary, but orchestration is what makes parallel agents useful. A worktree prevents two Cues from editing the same checkout, yet developers still need visible state, deliberate review, and a trustworthy merge boundary.

We learned that approval should be treated as short-lived evidence, not a permanent status. Tying acceptance to a fingerprint of the current diff makes the review gate understandable and enforceable. We also learned to persist the smallest durable truth: user instructions, lane state, conversation history, and branch identity can be restored, while diffs and approvals are safer to recompute.

Finally, a direct CLI integration can be a strong application boundary. By building around Codex and Git concepts instead of premature abstractions, we kept the architecture small enough to reason about and test thoroughly.

What's next for Codex Dirigent

Next we want to make the multi-Cue workflow even smoother with a clearer merge queue, better conflict explanations, Cue dependencies, and improved recovery and worktree cleanup controls.

We also plan to polish accessibility, make first-run and repository switching more explicit, expand release automation, and continue validating the workflow on larger real-world repositories. The guiding principle will remain the same: Codex can move quickly, while the developer stays in control of what reaches main.

note: read and adjustments by a human

Built With

• rust