Ditch Tracks Multiple Codex Agents

Ditch is DitchNow’s local desktop app for supervising several OpenAI Codex agents from one place. DitchNow is a team building tools they developed for their own needs, and the Community Edition ships under an AGPL-3.0 license. It deals with a very specific pain in Codex CLI workflows: once agents run across multiple repos, the hard part becomes knowing which session is active, waiting, failed, or ready for review. The takeaway is simple: parallel Codex work needs a cockpit before it needs more prompts. Ditch is a local session manager for Codex agents.

It sits beside OpenAI Codex, OpenAI’s coding agent, rather than replacing it. You still use Codex to do the work. Ditch tries to make the waiting, switching, and returning less messy.

Why developers noticed Ditch

The Hacker News post landed because the problem is familiar and a little embarrassing. A developer starts one Codex agent on a bug fix, another on a docs change, and a third on a small product branch. Then normal work interrupts. Thirty minutes later, the question is not “can the agent code?” It is “which terminal needed me?”

Ditch’s pitch is narrow: keep projects and sessions in one place, show active or waiting state, notify when something needs attention, and make it easier to move between projects without losing context. That is not a new model. It is a missing workbench.

The useful part is that Ditch treats Codex sessions as ongoing work, not disposable chats. That matches how many developers now use the codex cli: they give one bounded task to one agent, let it run, then come back for review. The trap is assuming “multiple agents” means “multiple finished products.” It mostly means multiple unfinished conversations that need clean handoff points.

The interesting trick is attention, not autonomy

Ditch is interesting because it manages attention. It answers the question a good terminal tab cannot answer quickly: “where should I look next?”

That matters because Codex agents often pause at human-shaped boundaries. They need a decision, a permission, a failing test interpreted, or a review of generated changes. If you miss that moment, the agent is not autonomous; it is just idle in a forgotten pane.

A concrete example: you ask one Codex session to add server-side pagination in apps/admin, another to update SDK examples in docs, and another to investigate a flaky test in packages/api. The work is independent. Your attention is not. Ditch’s job is to make the queue visible enough that you do not replay three transcripts just to remember your morning.

The trap is treating notifications as correctness. A notification can tell you a session needs attention. It cannot tell you the diff is good. The review still belongs to you.

Use it when sessions outnumber your memory

Ditch looks most useful when you already run two or more Codex sessions in parallel and feel the context tax. If you usually run one agent, wait, review, and merge, your shell and editor may be enough.

A good first use is boring work across separate repos: docs cleanup, dependency updates, small UI fixes, test repair, or migration prep. These tasks have a clear end state and do not require the same files. They also fit the stronger pattern behind Codex CLI workflows: small jobs, scoped instructions, visible verification.

It is overkill when the work is deeply coupled. Do not ask three agents to reshape the same payment flow unless you enjoy conflict archaeology. Parallelism is helpful when the branches are independent. It gets expensive when every result must be reconciled by hand.

If your bigger concern is isolation rather than dashboarding, the adjacent pattern is running agents in controlled environments; we covered one version in coop Runs Codex and Claude Code in VMs.

Keep each Codex agent on rails

The small workflow lesson from Ditch is this: a multi-agent dashboard only works if each agent has a tight job boundary. Otherwise you get a neat view of chaos.

For a repo using AGENTS.md, give Codex durable rules before you start parallel sessions. Put broad rules at the repo root. Put sharper rules closer to the code being changed. Local scope helps: the agent working in apps/admin should not need to infer API migration rules from a general prompt.

Here is a small AGENTS.md boundary that works well for parallel Codex work:

# AGENTS.md

## Scope
This directory contains the admin web app. Do not edit API packages, database migrations, or shared auth code from this task.

## Before changing code
- Read the nearest package.json and existing test commands.
- Prefer small diffs over broad refactors.
- If a task requires changing files outside this directory, stop and ask.

## Verification
Run the narrowest relevant check first:
- npm run lint --workspace=apps/admin
- npm test --workspace=apps/admin -- --runInBand

Report which commands passed, failed, or were not run.

That last line is the handoff receipt. It gives you something to scan in Ditch when a session says it is done. Without it, “finished” can mean “the agent stopped typing.”

If your Codex setup connects to an MCP server for GitHub, docs, tickets, or internal data, keep the first pass read-only. A simple Codex MCP boundary is: read issues, branches, and docs; do not write comments, mutate tickets, or push changes unless the task explicitly asks for it. The trap is giving every parallel session the same wide permissions and then being surprised when state changes outside the diff.

Try Ditch safely on one afternoon

Use Ditch on small, separate tasks first. The goal is not to prove you can run a swarm. The goal is to learn whether a local session manager lowers your switching cost.

A simple test is three sessions: one docs fix, one failing test investigation, and one small UI bug. Start them with explicit file boundaries. When Ditch marks a session waiting or finished, open the diff first, then the transcript.

Use this review loop before you trust any result:

git status
git diff --stat
git diff
npm test -- --runInBand

Swap the test command for your repo, of course. The important part is the order: inspect state, inspect shape, inspect details, verify behavior.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Common questions

• How should teams start with Codex?

  Start by writing down one visible team rule for Codex, not a loose preference. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Codex artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a AGENTS.md instruction, MCP note, or verification checklist. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Codex teams deciding which AGENTS.md instruction, CLI workflow, MCP boundary, or verification loop to standardize next around “Ditch Tracks Multiple Codex Agents.”
• Best first artifact: turn the named fix into an AGENTS.md rule, verification checklist, MCP note, or review receipt before the next automated run.
• Best comparison angle: compare the workflow against the current Codex CLI review loop, shell boundary, and evidence trail; keep the path that leaves the shortest auditable trail.

Further reading

• Ditch; Build multiple products at once — source
• OpenAI Developers — Codex CLI docs
• OpenAI Developers — Codex CLI
• OpenAI developers: guides agents md

Next move

Take this into the related training topic and test whether a new reviewer can defend the merge without replaying the chat.