Codex Background Agents and the Agents Dashboard, Explained
Published September 14, 2026 · by the AQ team
As of September 2026, Codex gives you four distinct ways to run coding work in the background: subagents that fan a single session out into parallel threads, the interactive agents dashboard (the codex agents command, added in Codex CLI 0.149.0 in August 2026) that manages many local tasks at once alongside codex queue for messaging them, codex exec for scripted unattended runs, and Codex cloud, which executes tasks in OpenAI-managed sandboxes and returns a diff or pull request. They compose: a dashboard full of local tasks can each be fanning out subagents under a shared token budget. What none of them change is where local work lives. Every session the dashboard shows runs on the machine that started it, so the machine's lifetime is still the ceiling on how "background" a background task really is.
Three different things "background" can mean in Codex
It helps to separate three shapes before reaching for any command:
- Parallel work inside one session. The main thread stays interactive while subagents handle bounded pieces. You keep one conversation; Codex multiplies underneath it.
- Many sessions on your machine. Several Codex tasks in separate terminals or panes, some interactive, some unattended via
codex exec. This is what the agents dashboard was built to manage. - Work handed off your machine entirely. Codex cloud runs the task in an OpenAI-managed sandbox and comes back with a result to review. Your laptop is free the moment you dispatch.
The first two keep everything local: your checkout, your credentials, your compute. The third trades custody for convenience.
The agents dashboard: codex agents and codex queue
Codex CLI 0.149.0 (August 20, 2026) added an interactive codex agents dashboard for searching, starting, opening, renaming, and stopping tasks, with configurable shortcuts. Run it from any terminal, or open the same view from inside a running session with the /agents slash command. It shows the root sessions the shared local app server knows about, with subagent status reflected under each one, and can group them by project or status. Before this existed, five concurrent Codex tasks meant five terminal windows and your own memory of which was which; now one screen answers "what is running, what is stuck, what finished."
The same release added codex queue, which sends a message to an existing session without opening it:
# See everything running locally
codex agents
# Queue an instruction for a task by name or session id
codex queue "also update the changelog" --name auth-refactor
Queued messages wake idle sessions, so you can steer a background task from a script or another terminal the way you would type into it interactively. Together the two commands turn a pile of terminal tabs into something closer to a task manager: start work, walk away from the window, check the dashboard later, nudge with a queue message where needed.
Subagents: parallelism inside one session
Subagents are separate agent threads that take bounded parts of a larger task: the main thread delegates, each subagent works with its own context, and the main thread collects the results. As of September 2026 you trigger delegation by asking for it directly ("spawn one agent per module and fix the imports"), or Codex follows AGENTS.md or skill instructions that request it. While threads run, the /agent command inspects and switches between them, and the agents dashboard shows their status under the parent session.
Fan-out is governed in config.toml under the [agents] section: max_threads caps concurrent agent threads (default 6) and max_depth caps nesting (default 1, so a child can work but not recurse into grandchildren). September 2026 also brought delegation policy to the app-server surface that the desktop app and IDE extension drive: multi-agent mode can be set to disabled, explicit-request-only, or proactive, at both the thread and the turn level, so a team can decide whether Codex volunteers parallelism or waits to be asked.
Subagents shine on read-heavy exploration, test triage, and genuinely independent chunks. They do not remove the coordination problem of two threads editing the same files; that remains yours to partition.
Rollout token budgets: keeping the fan-out affordable
Parallelism multiplies token spend, and September 2026's Codex releases added the matching control: configurable rollout token budgets. One budget is shared across all agent threads under a rollout, every thread records usage against the same ledger, Codex reminds you as the budget runs down (by default at intervals of 10 percent of the limit), and when the ledger is exhausted, turns abort rather than silently spending on. Configuration lives in config.toml:
[features.rollout_budget]
enabled = true
limit_tokens = 100000
reminder_interval_tokens = 10000
A budget is the difference between "the overnight run cost what we expected" and a surprise. If you script unattended work with codex exec, set one; an aborted turn you re-run in the morning is cheaper than an unbounded loop.
Codex cloud: off your machine entirely
Codex cloud runs tasks in OpenAI-managed sandboxes and hands back a diff or pull request. As of September 2026 you can dispatch from the CLI's codex cloud subcommand (with exec, status, list, apply, and diff verbs), from GitHub, from Linear issues, or from Slack, and run multiple attempts of the same task (best-of-N, up to four) to pick the strongest candidate. Tasks run in parallel without tying up your machine at all.
The trade is the execution environment: the sandbox is OpenAI's, provisioned per task from your repository, not your long-lived machine with your services, seeded databases, and internal network access. Fire-and-forget tasks with clear acceptance criteria fit it well. Work that needs your real environment, or that you want to watch and steer midway, fits the local layers better. The keep Codex running after closing your laptop guide compares these shapes in more depth.
The ceiling: local background tasks still live on your machine
Here is the limit that the dashboard, queue, subagents, and budgets all share: they manage processes on the machine that started them. The codex agents view reads sessions from the local app server. Close the laptop lid and every session it shows stops mid-task; the dashboard cannot outlive its host. codex resume recovers transcripts, not interrupted work.
The visibility boundary is the same. Your dashboard is yours: a teammate cannot open it, see that your refactor task has been waiting on an approval for an hour, or queue a message into it. And running the whole stack on a server you SSH into fixes lifetime but not visibility; the dashboard then lives in your tmux session on that box. The pattern is worth doing anyway, and running Codex on a cloud VM walks it end to end. The isolation from teammates is not a small thing: a July 2026 LeadDev analysis of 25,264 agent-generated pull requests across 2,361 popular GitHub repositories found that in 79 percent of agentic PRs the same developer both reviewed and modified the agent's contribution, and only about one in eight workflows involved multiple humans. Tooling that keeps each person's agents on each person's machine is part of why.
So the honest summary of the September 2026 Codex stack: excellent primitives for one person running many tasks on one machine, plus a managed cloud lane for work you are willing to hand off. The gap between those two, tasks that keep running when your laptop sleeps but still run on a machine your team controls and can watch, is where a persistent shared workspace comes in.
Where AQ fits
AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. In this guide's terms, AQ occupies the gap between the local dashboard and Codex cloud: Codex in AQ is the real CLI, agents dashboard and all, running in a persistent tmux session on your team's VM and streamed live to the browser. Sessions survive a closed laptop and resume from any device, so a background task started at the office is still executing, and still steerable, from a phone on the train.
The team boundary moves too. Teammates open the same workspace and watch the same live session; if you want a colleague to drive, they send a control request and you approve it in one click while keeping your own input. Each workspace gets an isolated git worktree on a branch named ai/{id}-{slug} with dependencies installed automatically, so parallel Codex tasks never trample each other's checkouts, and the PRs agents open are tracked per workspace. You sign into Codex with your own OpenAI account (per-user CLI logins; AQ never marks up usage on your own subscriptions), and Linear issues labeled ai-task become workspaces where a person, never an automation, starts the agent.
If you are one engineer on one machine, the September 2026 Codex primitives above are genuinely good, and you should use them. AQ earns its place when the tasks need to outlive the laptop and the team needs to see them.
Frequently asked questions
What is the Codex agents dashboard?
An interactive view added in Codex CLI 0.149.0 (August 20, 2026), opened with the codex agents command from a terminal or the /agents slash command inside a session. It lists the local tasks the shared app server knows about, shows subagent status under each root session, groups by project or status, and lets you search, start, open, rename, and stop tasks from one screen.
How do I send instructions to a Codex task that is already running?
Use codex queue, added alongside the dashboard in Codex CLI 0.149.0. It targets an existing local or remote session by exact name or session id and appends your message without opening the task, waking the session if it is idle. It is the piece that makes unattended tasks steerable from scripts or other terminals.
Do Codex background tasks keep running when I close my laptop?
Local ones do not. Sessions in the agents dashboard are processes on the machine that started them, so sleep or shutdown stops them mid-task, and codex resume restores the transcript rather than the interrupted work. To survive a closed lid, the task has to run somewhere that never sleeps: Codex cloud's managed sandboxes, a VM you run yourself with tmux, or a persistent shared workspace like AQ, where the CLI runs on your team's VM and streams to the browser.
How do Codex subagents get triggered and limited?
As of September 2026, Codex delegates to subagents when you ask directly or when AGENTS.md or skill instructions request it, and app-server clients can set multi-agent mode to disabled, explicit-request-only, or proactive at the thread and turn level. Fan-out is capped in config.toml under [agents]: max_threads (default 6) and max_depth (default 1). The /agent command inspects and switches threads while they run.
How do I stop parallel Codex agents from burning tokens overnight?
Set a rollout token budget, added in September 2026. It is one shared ledger across all agent threads under a rollout, configured under [features.rollout_budget] in config.toml with a limit_tokens cap. Codex reminds you as the budget depletes (default intervals of 10 percent of the limit) and aborts turns once it is exhausted, so an unattended run has a hard ceiling instead of an open tab.