The Best IDE for Agentic AI Is Not an IDE: Multi-Agent Context Management and Codex CLI
The Best IDE for Agentic AI Is Not an IDE: Multi-Agent Context Management and Codex CLI
Steve Yegge asked a simple question on X: which IDE do you use to manage multiple coding agents? Six hundred engineers replied, and nobody agreed.1 The responses ranged from thirty terminal tabs to home-built session managers to half a dozen tools that had never heard of each other. The absence of consensus is itself the signal. The industry has shipped the agents; it has not shipped the workspace.
This is not a complaint about model quality. The agents themselves — Codex CLI, Claude Code, Antigravity CLI — are capable. The problem is the human layer above them. When three agents are running in parallel — one investigating a performance regression, one untangling a dependency conflict, one drafting a migration script — the bottleneck is not compute. It is your ability to hold the state of all three conversations in your head, return to each at the right moment, and make decisions without having to reconstruct context from scratch. That reconstruction cost is where your productivity gains disappear.
Codex CLI gives you more scaffolding for this problem than most developers realise. But there are real gaps, and understanding both is the difference between a fluid multi-agent workflow and thirty terminal tabs.
What Codex CLI Already Gives You
The most underused feature for multi-agent work is codex queue. It is designed precisely for the problem Yegge’s thread was describing: multiple tasks running concurrently, each requiring a decision at unpredictable intervals.
# Fan out three tasks simultaneously
codex queue "investigate p95 latency spike in payments-service since deploy 4.2.1"
codex queue "audit dependency tree for packages with known CVEs filed after 2026-01-01"
codex queue "draft migration plan from REST to gRPC for the reporting module"
The queue runs agents concurrently (default six threads) and surfaces results as each task completes. You do not need to watch each terminal. You do not lose the context of what you asked. The task description travels with the result.
Session persistence is the second piece. Since v0.153.0, the --session flag and tui.auto_recap give you named session handles and automatic context summaries. When you return to an agent mid-task, the recap tells you where it is and what it decided. You are not reading scroll-back; you are reading a structured summary.
# config.toml
[tui]
auto_recap = true
auto_recap_interval = 10 # summarise every 10 turns
Guardian history (introduced v0.153.0, PRs #41879 and #42065) persists the approval record across sessions. If an agent requested a destructive action in a previous session and you declined, that context is available in the next session. The agent does not ask again as if the conversation never happened.
Together, these three features — queue, auto_recap, Guardian history — form the foundation of a Codex-native multi-agent workspace. Most developers do not configure them. Most developers are using thirty terminal tabs.
The Context Collapse Problem
The failure mode that Asay’s InfoWorld piece describes is not technical — it is cognitive.1 A developer managing three concurrent agents faces a prioritisation problem: which agent needs attention first, and why?
The naive answer is “whichever one just finished.” That is roughly what notification recency gives you, and it is wrong. The agent that completed five minutes ago may have surfaced a blocking decision whose delay has downstream consequences for the other two tasks. The agent still running may need a mid-course correction before it digs deeper into a wrong approach. Time-to-completion is the wrong signal.
What you actually need is decision impact. Which completion requires a choice that affects another running task? Which question, if answered wrong, forces a rework cycle? This is context Codex CLI does not currently emit in a queryable form, and it is why developers are building custom dashboards and workspace switchers in their spare time.
The practical mitigation available today is explicit task sequencing in AGENTS.md. If you know that the gRPC migration depends on the dependency audit completing first, encode that dependency:
## Task Dependencies
Migration tasks must not begin until the dependency audit for the affected module is
committed. Reference: `codex queue --session audit-001` must reach status `complete`
before `codex queue --session migrate-001` proceeds past the design phase.
This is manual. It requires you to have thought through the dependency graph before starting. But it prevents the agent from making progress in a direction that will need to be reversed when the upstream task resolves differently than expected.
Milestone-Based Session Grouping
Several engineers in Yegge’s thread described milestone-based workspace switchers: a view that groups agent conversations by the sprint goal or project milestone they contribute to, rather than by recency or task type. Jacob Voytko’s implementation — built as a shell layer over tmux — is representative of the pattern.1
Codex CLI does not have native milestone grouping, but codex queue tags give you a workable approximation:
# Group tasks under a milestone tag
codex queue --tag "sprint-47-perf" "profile hot paths in payments-service using async-profiler"
codex queue --tag "sprint-47-perf" "identify N+1 queries in order-history endpoint"
codex queue --tag "sprint-47-perf" "draft caching strategy for catalogue lookups"
# List all tasks for the milestone
codex queue list --tag "sprint-47-perf"
The tag is a lightweight label, not a dependency constraint. It does not enforce ordering or block on completions. But it gives you a filtered view of which conversations belong to the same goal, which is the first step toward a milestone-based workspace.
For teams using codex queue at scale, a short shell function that wraps both tagging and status display is worth the ten minutes it takes to write:
# In your .bashrc or .zshrc
cq-sprint() {
local tag="${1:-current-sprint}"
codex queue list --tag "$tag" --format json \
| jq -r '.tasks[] | "\(.status)\t\(.id)\t\(.description[:60])"' \
| column -t
}
Small, opinionated tooling built around codex queue covers most of what the custom workspace switchers in Yegge’s thread were doing. The gap that remains is decision-impact scoring — knowing which blocked task is most urgent — and that requires either a purpose-built orchestration layer or a disciplined habit of writing explicit dependency metadata into your AGENTS.md before starting a batch of tasks.
What the Tooling Ecosystem Needs to Build
The tools that Herdr, Conductor, and the other entries in Yegge’s thread are attempting to solve have a common shape: they want to bring the human back into the loop at the right moment with the right context.1 Not all completions, not all notifications — the specific decision whose delay compounds cost.
For Codex CLI, this means a few things the current release does not provide:
Decision-impact scoring. When a task reaches a decision point, the output should carry a signal about which other running tasks are affected by the outcome. This requires the agent to reason about task interdependencies, which is currently outside its remit.
Rejected-approach memory across tasks. Guardian history persists approval decisions within a session. It does not currently propagate a rejected approach in task A as context for the parallel execution of task B. If both tasks are exploring the same design space, the rejection in A is relevant to B.
Unified task surface. codex queue list is a CLI command. It is not a persistent ambient display. When you are deep in another task, you do not see it. A persistent sidebar — in a terminal multiplexer, an IDE extension, or a standalone TUI — that shows task status and pending decisions without interrupting your current context is the missing primitive.
None of these are blockers for using Codex CLI for multi-agent work today. They are the reasons why developers with three to ten concurrent agents have started reaching for custom tooling, and why the category Yegge’s thread was probing — call it agentic workspace management — is an unsolved problem waiting for either a third-party tool or a first-party investment from OpenAI.
What to Do Now
Configure codex queue, auto_recap, and Guardian history today if you have not already. Run your concurrent tasks under tags. Write dependency constraints into your AGENTS.md before launching related tasks rather than discovering the conflicts afterwards. Keep your queue to six concurrent tasks at most — beyond that, the reconstruction cost per decision point starts to exceed the parallelism benefit.
When you hit the ceiling of what the current tooling supports, the right investment is a short shell layer around codex queue that filters by tag, surfaces blocked tasks first, and pipes summaries to a persistent display in your terminal multiplexer. That covers eighty per cent of what the custom workspace switchers in Yegge’s thread were doing, without requiring you to maintain a separate application.
The IDE for agentic AI is not an IDE. It is a disciplined queuing discipline, a habit of explicit dependency annotation, and a thin shell layer that surfaces the right decision at the right moment. Build the habit first; the tooling will follow.