Codex and Subagents

Writing code is only part of a software engineering task. Someone also has to explore the repository, run commands, execute tests and interpret what happened. Codex brings those activities into the same agent workflow. Katia Gil Guzman and Vaibhav Srivastav, who goes by VB, introduce it from their work on OpenAI’s Developer Experience team in London.

The model supplies capability; the harness makes that capability usable in an environment. Katia names GPT-5.3-Codex, its fast Spark variant, GPT-5.4 and a recently released mini model as the foundation available at the time. Above that foundation sits a unified agent harness responsible for tool execution, environment setup, agent behavior and safety. The app, IDE extension and CLI expose that system through different interfaces; Slack and GitHub offer additional places to delegate work. Integrations with Figma, Linear and Notion connect the agent to the surrounding engineering workflow.

VB traces the progression from GPT-5.2 to GPT-5.2-Codex, which pushed longer-running tasks, then GPT-5.3-Codex and GPT-5.3-Codex-Spark, developed in partnership with Cerebras. GPT-5.4 follows as the newest frontier model in the workshop. Alongside those larger models, GPT-5.4 mini and GPT-5.4 nano target shorter tasks and subagents. The resulting choice is about both the difficulty of an assignment and how much time and compute it deserves.

Serving changes address another part of the delay: communication between the device and the API. VB reports roughly 1.75× faster tokens from WebSockets, without passing an additional cost to users, followed by another 2× token-speed improvement from fast mode. He does not specify the workload or measurement baseline, so these remain his workshop figures rather than a measured combined speedup. The later speed documentation describes 1.5× model speed for fast mode and 2× Standard credit consumption for GPT-5.4; that distinction should not be read backward as a specification of the demonstrated build.

The app becomes useful when work spreads across projects and features. Its sidebar groups projects such as Codex, ChatGPT and Sora. Within a project, Git worktrees give simultaneous feature work, bug fixes and investigation separate working directories, reducing interference between tasks. Native Git support then lets the user push changes with the appropriate Git identity.

Automations add scheduled work: a process can run every morning, every evening or produce a calendar briefing. The platform story also broadens from the original macOS app to Windows with a native Windows sandbox. VB describes that sandbox as a first among competing harnesses at the time, a contemporaneous competitive claim rather than a requirement for using the workflow.

The next features extend this workspace in complementary ways. Plugins package skills, MCP tools and prompts; smaller models make parallel subagent assignments less expensive; code review and security help inspect the resulting work. As an adoption snapshot, VB reports that Codex crossed 3 million weekly active users the previous night, and Katia adds that usage had more than tripled since January.

Plugins bundle several kinds of capability into a reusable workflow. The components have different jobs:

A skill saves repeated explanation of a familiar process, and Codex can help write it. A plugin packages the pieces that would otherwise require separate setup, though external services can still require their own authorization. Automations reuse those capabilities in scheduled background instructions, much like a cron job.

For visual development, Katia combines two complementary skills. Playwright Interactive lets Codex open an app, navigate, click controls, take screenshots and analyze what appears. ImageGen supplies visual assets and sprites. Together, they connect asset creation with inspection of the application that uses those assets.

She starts a build using the Game Studio plugin, explicitly requesting ImageGen assets and Playwright Interactive debugging. Katia reports that the previous day’s game build took about an hour. She therefore starts the live task early and keeps that completed version available to inspect while the new build runs.

The next task connects a repository to a business document. The developer website stores Codex meetup records in YAML files. Katia has installed the Google Drive plugin and connected her account, then prepared a spreadsheet called Codex Events with columns for event name, date and city. She asks Codex to populate it with the current meetups from the codebase. The plugin catalog includes featured integrations, but users can also supply their own plugins.

While the spreadsheet task runs, she shows recurring work already handled by automations:

• Slack triage: Every day at 9 a.m., identify messages awaiting a reply, flag urgent requests, summarize activity since yesterday by topic and surface important company updates.
• Gmail triage: Identify messages that merit a response, assess time sensitivity and flag whether a request appears legitimate.

Katia says this email triage saves her hours per day. That is her experience with her own inbox and workflow.

She then asks for a new automation that searches Slack for Codex use cases worth putting on the website. Conversational creation does not reliably produce the expected setup popup, even after she asks again. The manual path makes the required configuration explicit:

1. Open the automation creation interface.
2. Supply the task instructions and select the plugin, here Slack.
3. Choose the frequency.
4. Choose the project in which the automation should run.

The live attempt illustrates the difference between describing a recurring task and successfully saving its schedule.

Returning to the repository task, Katia reports that Codex spent two minutes analyzing the codebase, found the event YAML sources and wrote 57 event rows. She then opens the spreadsheet and checks that it is populated. This closes the loop from source discovery to a visible change in the connected service.

The same pattern applies to data review: give Codex access to the relevant repository records, add other inputs such as CSV files, and ask it to perform the transformation or reconciliation. The spreadsheet demonstration is useful because the output is a concrete artifact that can be inspected independently of the agent’s narration.

The live game task is still generating sprites and other assets. Browser inspection with Playwright is described as its next step, so Katia switches to the previous day’s completed build. She says she has not modified that result after generation. The original request was simply: “Do a platformer game with platforms made of bricks.”

The overall interface still deserves iteration, but the character animation shows what asset generation contributes. Katia points out at least five different character sprites while moving through the game. She suggests a further variation: provide a face image and generate a custom 2D player character. Game Studio packages the supporting skills together, with a corresponding bundle available for web-app development.

Plugin Creator can help build custom bundles, but delegating more work also creates a review problem: several agents can produce changes faster than one person can inspect every line. Code review becomes a first pass over that growing output. VB calls Codex’s review quality industry-leading while explicitly acknowledging his own bias.

Review is available where changes are already being handled:

• GitHub: Connect a ChatGPT account and configure automatic pull-request reviews, with inline findings carrying severity labels such as P0, P1 and P2.
• App and CLI: Invoke /review to start a review process.
• Claude Code: Use the Codex plugin for Claude Code to request a Codex review within that session.

These are different entry points into the review workflow, rather than a requirement to move all development into one interface.

In the live example, VB chooses to review uncommitted changes; the interface also offers comparison against a selected branch. Codex opens a new thread and process with a dedicated review system prompt. It examines the diff in the context of the monorepo, allowing it to investigate consequences in modules that the change did not touch directly. VB reports that 100% of employee pull requests across OpenAI repositories receive Codex review by default. He describes that review as the first pass.

VB reports that the demonstrated review took about one minute and returned P1 localization and P2 translation findings. The completed view lists untranslated dashboard content. From there, he can ask Codex to fix the findings or open a follow-up pull request. The review thread supplies findings; remediation is a subsequent task.

Subagents let a coordinating agent delegate independent parts of a task and collect the results. API or subscription capacity constrains how much work can run, and the live example will expose a separate configured concurrency limit. The useful decomposition is one in which each agent can make progress without waiting for another agent’s answer.

VB’s example is a collection of roughly forty to fifty subagent personas that need review after a specification change. The repository was private at the time. Instead of reviewing every file sequentially, the coordinator can assign small review slices—perhaps two files to Polly and another pair to Plato—then collate their findings. The collection includes documentation reviewers, test creators, test runners, an accessibility reviewer and an architect. Each persona carries a name, description, sandbox configuration and instructions.

For the live run, VB selects medium reasoning effort and requests twenty subagents. Codex discovers 45 curated persona TOML files and plans twenty review slices. It displays a five-task checklist, which VB describes as automatically entering plan mode; he notes that planning can also be requested explicitly. Partitioning comes before dispatch: the coordinator first establishes what each reviewer should own.

The request for twenty reviewers encounters a configured limit of six concurrent agent threads in VB’s setup, so six agents initially launch. This is a limit of that setup, not a universal six-agent rule. VB opens individual threads, including Jason and Hume, to inspect their work. Each assignment includes a role, the exact files to review and pointers to repository guidance in repo.md, contributing.md and skills. Completed agents are torn down, and their feedback returns to the main thread for collation.

Partitioning files is only one way to divide work. Several agents can examine the same commit or repository through different vulnerability hypotheses and contribute to a vulnerability map. For feature planning, VB first asks for several implementation approaches, then delegates investigation of those alternatives. Here, the independent unit is a question or hypothesis rather than a separate file.

The workshop describes three built-in personas:

Custom personas refine these roles with a model, reasoning effort, sandbox settings and instructions. VB recommends read-only access for reviewers and vulnerability investigators, while documentation and bug-report authors may need write access. Read-only constrains mutation; it should not be interpreted as a blanket statement that no command can run.

Tools can be assigned by role too. A Sentry-connected agent can inspect reports; a Linear-connected agent can read a backlog or triage assigned issues. Skills add reusable procedures. This lets a persona specify both how to reason about the task and which external information it can access.

When VB returns to the audit, the coordinator has produced findings grounded in the repository’s README and contributing guidance. It flags an over-privileged performance investigator and sandbox mismatches for the verifier and writer personas. Those findings make the permission question concrete: a persona’s declared job and its configured access can disagree.

Custom personas can be written directly or suggested by asking Codex to inspect recurring work in past sessions. VB’s PR Explorer uses GPT-5.3-Codex-Spark, described here as a text-only research preview running on Cerebras. Its sandbox is read-only, and its instructions keep it in exploration mode: trace execution paths and do not propose fixes. A compact TOML persona expressing that scope is:

name = "pr_explorer"
description = "Trace code paths relevant to a pull request."
model = "gpt-5.3-codex-spark"
sandbox_mode = "read-only"
developer_instructions = """
Stay in exploration mode.
Trace the execution paths relevant to the assigned question.
Report the files and functions that explain the behavior.
Do not edit files or propose fixes.
"""

The role has a clear stopping point: return an explanation of the relevant behavior for the coordinator to use.

Next, VB supplies a documentation-research persona in natural language and asks Codex to create it. Codex is expected to write and place the TOML file, then attach the Developer Experience team’s documentation MCP server. That server exposes API references, documentation, guides and toolkits. Example questions include using GPT-5.4 with WebSockets or working with the realtime API and a React integration. The tool connection gives the researcher a source to consult while answering.

The new reviewer can then be requested by role to check the persona collection against developer documentation. Other proposed roles include running local tests during long builds, retrieving GitHub updates and gathering context from a Linear issue. VB’s recurring recommendation is to ask Codex to look through previous sessions and suggest the automations or subagents that match work already being repeated.

Guardian approvals are presented as an experimental feature enabled through /experimental. The motivation is approval fatigue: repeated prompts can encourage users to grant unrestricted access simply to keep work moving. VB warns against that approach and describes an additional agent that reviews requests for privileged actions.

The examples include removing a directory, starting a server and exposing a file to the internet. When such an action needs approval, a separate prompted subagent assesses whether human intervention is necessary. VB says most reviewed actions can proceed without interruption, with the aim of reducing routine approval burden. In the live demonstration, however, difficulty changing full-access mode prevents a clear result from the request to start a development server. The mechanism is explained, but that attempted invocation does not establish a successful guardian decision.

Hooks provide a programmatic response to an agent lifecycle event. VB introduces experimental hooks for after tool use, session start and stopping. His examples are pulling the latest repository state at startup, recording tool activity for research, and asking a long-running task to continue when it would otherwise stop.

The configuration example pairs hooks.json with Python scripts and event matchers, including startup or resume conditions. VB refers to pre-tool use while discussing that configuration, although the earlier list said after-tool use. For implementation, these names need to be kept distinct: current hooks distinguish PreToolUse from PostToolUse, and Stop from SessionEnd. The workshop’s spoken three-event list is not a current API specification.

For the sales dashboard, the stop hook invokes keepgoing.py. Its continuation instruction asks Codex to make one more pass, run one solid validating command, tighten one more thing, then stop and report the result. That turns a vague request to continue into a bounded follow-up unit of work. The displayed script illustrates the instruction; the workshop does not show a completed execution of that hook.

Personalization controls adjust communication style, with friendly and pragmatic personalities shown as options. Custom instructions add persistent preferences—for example, asking Codex to cite the work it is doing. These settings shape interaction with the agent without requiring a new task-specific persona each time.

Codex Security extends the review workflow to application vulnerabilities. It is an application security agent using frontier models and Codex. VB describes it examining GitHub projects commit by commit, identifying vulnerabilities and producing patches with Codex-assisted remediation.

The feature tour ends by returning to the Claude Code integration. It can ask Codex to review existing changes, conduct an adversarial review or rescue an in-progress change set. This makes a second agent available inside the workflow already producing the code.

The first audience question makes the session-history suggestion concrete: how would Codex inspect a project with roughly twenty threads? VB points to locally stored sessions under the Codex directory, describing the location verbally as .sessions inside .codex. His practical instruction is to ask Codex to look through previous sessions; he says this can be done through either the app or CLI. The useful entry point is that request, rather than assuming the spoken directory name is a verified filesystem path.

Another attendee asks whether a task can move to the cloud when they need to close their laptop. Katia shows the choice between local work, worktrees and cloud execution. Cloud tasks also support best-of-N: run the same task several times in parallel and choose an output, with four runs as her example. She names the app, IDE extension and web interface as access points. This demonstrates selecting cloud execution, not the mechanics of transferring an already-running local process and its state.

The final question exposes a limit of the workshop’s cloud workflow. An attendee says cloud subagents are unsupported, and VB agrees. Asked about skills, he offers no firm delivery date. Trusted MCP servers, additional CLIs and SSH agents receiving tasks on virtual machines are discussed as directions for future work.

The speakers then separate two capabilities that can look similar from the outside. VB says cloud tasks do not support skills in the sense under discussion; Katia points out that checked-in instructions and resources remain part of the repository and can be read. VB explains the trust concern: a skill may bundle a Python script or another executable, and the sandbox needs a basis for trusting it. Reading a repository resource and authorizing a packaged executable are different operations. The final practical advice is to explicitly ask the cloud task to consult the relevant repository resources, while recognizing that this does not reproduce the full locally installed skill workflow.