Codex CLI Adds Voice and Multi-Agent Support

OpenAI has updated Codex CLI with voice conversations, an `/agents` multi-agent task view, and built-in worktree support. It is evolving from a terminal-based coding assistant into a development console capable of orchestrating tasks in parallel.
In its latest DevDay 2026 announcement, OpenAI upgraded Codex CLI: developers can now use voice to start, follow up on, and adjust coding tasks, while a new /agents view lets them split work among multiple agents and track progress.
Launching alongside these two headline features are prompt editing, session recovery, built-in worktree support, and a redesigned terminal interface. Based on the information disclosed so far, this CLI update is available across all plans.
This is not merely a cosmetic overhaul of the interaction layer. OpenAI is transforming Codex CLI from “an AI chat box in the terminal” into a local console for agent-driven tasks: humans set goals, correct course, and review results, while multiple agents execute in parallel across different contexts and code branches.

Voice Comes to the Terminal, and Its Value Goes Beyond Typing a Few Fewer Lines
With voice interaction added to Codex CLI, developers can speak tasks directly, add constraints through ongoing conversation, and adjust direction while tasks are running.
The typical use case is not asking Codex to transcribe a function, but higher-level coordination such as:
- Investigate the test failure from earlier, but do not modify production code yet;
- Split the database migration and API compatibility check into two tasks;
- Pause the frontend refactor and prioritize the authentication regression;
- Explain the current blocker, then proceed with the lowest-risk option;
- Commit only the tests and documentation, leaving the core implementation in the worktree for human review.
The keyboard is, of course, more precise. But once agents begin running continuously for 10 minutes or longer, human–computer interaction is no longer primarily about entering instructions line by line. Instead, it becomes about making frequent, low-cost course corrections. In this context, voice is more like giving verbal directions on a project site than traditional speech-to-text.
This change is especially useful for long-running tasks. Previously, developers often had to wait for Codex to produce a lengthy result before composing a complete follow-up prompt. Now, they can add conditions while it is still working. When reviewing logs while switching between a browser and an IDE, avoiding even one window switch is more practical than the marketing notion of “coding by voice.”
However, voice can also amplify ambiguity in prompts. Expressions such as “fix all of these” or “go ahead and commit that too” are already insufficiently precise for human colleagues, and they pose even greater risks when addressed to an agent with permission to modify files and execute commands. Voice is suitable for coordination, but that does not mean it should bypass confirmation.
OpenAI’s disclosures so far have focused on the ability to start and guide tasks by voice, but several implementation details still need to be evaluated:
- Whether recognition of terminal commands, filenames, and variable names is reliable;
- Whether the system can reliably distinguish instructions from background conversation in noisy environments;
- Where voice data is processed, how it is retained, and what enterprise controls are available;
- Whether high-risk operations still trigger clear permission prompts;
- Whether voice context in long-running sessions affects task decisions.
Voice is therefore a useful input channel, but it is not a permission system. Teams should not hand over production credentials, deployment access, and irreversible commands simply because the interaction feels more natural.
/agents Is the Real Centerpiece of This Update
Compared with voice, the new /agents view deserves more attention from development teams.
In single-agent mode, Codex typically handles tasks sequentially: reading the repository, understanding the requirements, modifying code, running tests, and then iterating based on the results. The problem is that when a task contains multiple relatively independent subproblems, serial execution compounds model latency, test runtime, and context-switching overhead.
The multi-agent view allows developers to assign work to multiple agents and see the status of every task in one place. It resembles a lightweight task board in the terminal—or a combination of tmux and a ticketing system designed for AI processes. Each agent maintains its own task context, so developers no longer need to search through multiple sessions to determine what each one is doing.
For example, an upgrade to a payment module could be divided into four parallel workstreams:
- Agent A: Map the payment APIs and their call relationships;
- Agent B: Update the SDK and type definitions;
- Agent C: Add unit tests and regression cases;
- Agent D: Review documentation, migration notes, and compatibility risks.
An illustrative terminal workflow might look like this:
$ codex
> Split the payment API upgrade into three tasks: implementation, testing, and compatibility checks.
> Use a separate worktree for each task. Do not modify the main branch directly.
/agents
Agent A API implementation running
Agent B Regression testing waiting
Agent C Compatibility checks completed
The example above merely illustrates the workflow; it is not a verbatim reproduction of the final interface fields or output format. The key point is that, for the first time, developers can clearly see multiple agents within the CLI instead of opening three or four terminal windows and relying on memory to keep track of which session is changing which files.
However, multiple agents do not inherently mean higher quality. What they improve first is parallelism; only then might they improve completeness. If task boundaries are poorly defined, three agents may all modify the same entry-point file, creating more conflicts than a single agent would.
What truly determines effectiveness is whether work can be divided into loosely coupled units that can be validated independently. Expanding test coverage, updating documentation, mapping dependencies, performing static checks, and migrating modules are usually suitable for parallel execution. Cross-module architectural refactoring, database schema changes, and global state redesign depend more heavily on a unified design and cannot be solved simply by adding more agents.
Built-In Worktrees Give Parallel Changes a Place to Land
This update also adds built-in worktree support. It may not be as eye-catching as voice or multi-agent features, but it could be the foundation that determines whether the entire parallel workflow can function in practice.
Git worktrees allow a single repository to be checked out into multiple working directories at the same time, with each directory corresponding to a different branch. For human developers, this eliminates frequent branch switching. For multiple coding agents, its more important purpose is to isolate file changes.
If multiple agents share the same directory, even when their tasks are independent, several problems may arise:
- One agent may overwrite another agent’s uncommitted changes;
- Test results may be contaminated by temporary files from other tasks;
- Dependency installation or code generation may alter a shared directory;
- An agent may be unable to determine whether a particular diff was produced by itself;
- The final commit may accidentally bundle several tasks together.
Placing each agent in a separate worktree is equivalent to giving every worker an individual workbench. They can share the Git object database while maintaining separate checkout directories and branch states. This allows developers to review each diff and run each set of tests independently before deciding which results should be merged.
It is important to note that worktrees solve only file and branch isolation; they do not automatically resolve logical conflicts. If two tasks both change the same shared interface, the final merge will still require human intervention or an additional agent. Databases, container ports, cache directories, and external test environments are not necessarily isolated automatically with Git worktrees either.
In other words, worktrees reduce the likelihood of agents stepping on one another’s files, but they do not turn parallel development into conflict-free development.
Long Sessions Are Finally More Than Just Scrollback History
Codex CLI has also redesigned its terminal interface and improved prompt editing and session recovery. For short tasks, these are merely quality-of-life improvements; for agent tasks that run for hours, they directly affect controllability.
Traditional chat interfaces stack everything chronologically. As a session grows, command output, model explanations, tool calls, and error logs merge into a single stream of information. To determine “what the model changed,” “why the tests failed,” or “what it is currently waiting for,” developers often have no choice but to scroll back through the terminal.
A clearer terminal interface, combined with a dedicated agent status view, indicates that OpenAI is beginning to treat observability as a core product capability for coding agents rather than an add-on. The longer an agent runs, the more developers need visibility into status, permission requests, failure causes, and output locations—not merely a continuously blinking activity indicator.
Session recovery is equally important. CLI tasks may stop because of network instability, terminal closure, device restarts, or deliberate interruption by a developer. If developers must explain the repository context to the model all over again after resuming, the efficiency gains of long-running tasks quickly disappear. The practical value of recovery will depend on how much state it preserves: only the conversation text, or also the task plan, working directories, tool results, and dependencies among agents.
Codex Is Evolving From a Code Generator Into a Task Orchestrator
This upgrade reflects a clear direction for AI programming tools: competition is shifting from “who can generate a more accurate code snippet” to “who can reliably complete a multi-step engineering task.”
Code generation remains important, but differences among models are increasingly being reframed through workflow capabilities. Even if a model produces stronger individual responses, it will struggle to take over long-running work in real repositories if it cannot isolate changes, manage tasks, recover sessions, and present execution status.
The advantage of Codex CLI is that it brings voice instructions, multiple agents, worktrees, and terminal status into a single local interface. Developers can experiment with parallel tasks without building a separate agent orchestration framework.
Its limitations are equally clear: a CLI may present tasks in a unified view, but that does not mean it has solved dependency management among agents, code ownership, merge strategies, or accountability for quality. A task list that appears entirely green may still produce implementations that cannot be merged, or changes that pass local tests while violating system-wide constraints.
This update therefore looks more like an effort to move “multi-agent programming” from a hacker experiment into a product suitable for everyday use—not a declaration that software engineering can now operate unattended.
What Teams Really Need Is Governance, Not More Agents
Teams preparing to use the new Codex CLI in real projects should address at least the following issues first:
1. Minimize Default Permissions
By default, agents should have access only to the directories, commands, and credentials needed to complete their tasks. Production databases, cloud administration keys, and release permissions should not become automatically available simply because the CLI is running on a developer’s computer.
2. Define Acceptance Criteria for Every Task
Do not simply say, “Fix the payment module.” A better task description should specify the affected directories, tests that must pass, interfaces that must not be changed, and the deliverables that must be produced.
3. Limit Concurrency
Running more agents simultaneously increases model usage, test resource consumption, and the likelihood of code conflicts. More concurrency is not always better, especially when agents share large build caches or integration testing environments.
4. Preserve Human Review and Merge Steps
Worktrees and separate branches are useful for isolating changes, but final merges should still undergo diff review, testing, and security checks. Agents should not be allowed to merge directly into the main branch for high-risk modules such as authentication, billing, and data migration.
5. Record Task Origins and Action Trails
Voice lowers the barrier to issuing instructions, but it may also reduce their traceability. Teams need to confirm whether voice instructions are transcribed, how they are stored, and whether they can be linked to specific commits and tool calls.
Verdict: Useful, but Its Value Comes Mainly From Orchestration, Not Voice
Viewed in isolation, voice interaction makes this update easy to interpret as merely adding a microphone button to the terminal. But when /agents, session recovery, and worktrees are considered together, OpenAI’s goal becomes clearer: enabling a single developer to manage a group of continuously operating coding agents from the terminal.
Voice reduces coordination overhead, /agents presents parallel tasks, worktrees isolate code, and session recovery extends task lifecycles. Only when combined do these four features form a relatively complete agent-driven development workflow.
For individual developers, the most immediate benefit of the new Codex CLI is the ability to split testing, documentation, investigation, and implementation into parallel workstreams. For teams, its value depends on whether permission controls, review processes, and merge workflows can keep pace. Without those safeguards, multiple agents will merely produce more changes faster—not necessarily production-ready software faster.
This update is worth using, but it does not justify blindly automating everything. Treating Codex as an engineering execution layer that can be orchestrated in parallel is closer to its actual capabilities today than treating it as an unsupervised virtual development team.
References
- ITHome: OpenAI Codex CLI upgraded with voice interaction and a redesigned terminal interface — A summary of the voice,
/agents, worktree, and terminal interface updates announced at DevDay 2026. - Reddit: Discussion of multi-agent group chat experiments with Codex — Community experiments with dynamic agent teams and status management; not official product documentation.
- Zhihu: Discussion of voice-controlled complex tasks and interactions with Codex — Background information and scenario-based discussion of using voice to control agent tasks.


