A wrapper script can run Codex CLI as a child agent and return its answer to the parent session through standard output.
2
The hardest part is configuring Codex's sandbox permissions, especially access to credentials, workspace files, and the rollout recorder.
3
Agents.md can teach Codex when to use subagents and how to invoke them without repeated permission prompts.
Summary
Brian John shows how to add subagents to Codex CLI, which does not provide them directly. His design uses a parent Codex session, a wrapper script, and a child process launched with codex exec. The child receives its agent name and query through files, writes its result to a file, and returns that result through standard output. Most of the implementation is small, but Codex's sandbox makes permissions difficult. The parent needs workspace sandbox access, while the child needs workspace write access, access to copied Codex home files, and a disabled rollout recorder. John also discusses the security tradeoffs using Meta's Agents Rule of Two. A proof-of-concept repository contains toy word-counting and file-writing agents. The approach works, though Codex runs subagents serially and can take several minutes on large codebase tasks. The talk is practical and candid about the setup effort and limitations.
John uses subagents to manage context. The parent agent gives a problem to a child, which spends its own tokens doing the work and sends only the answer back. The child's intermediate context does not fill the parent's context window. This lets him reuse workflows across tools and model families instead of staying with one coding assistant. He credits Dex Hory's talk with changing how he works with AI, especially on large codebases.
The design has a parent Codex session run a wrapper script. The script determines which agent to use, builds the prompt, and starts codex exec. The child Codex process does the work and writes its answer to a file. The wrapper reads that file and prints the result to standard output, which gives the answer back to the parent session. John describes the design as simple, but the sandbox configuration makes the implementation harder than expected.
Sandbox permissions are the hardest implementation detail
The parent needs at least workspace sandbox access so it can run the Codex command. The child needs workspace write access to create the result file. Codex's sandbox also blocks access to OpenAI credentials in the home directory, so John's wrapper copies the required Codex home files into a subdirectory and points CODEX_HOME there. He also disables the rollout recorder because the parent sandbox blocks filesystem access to subcommands outside the workspace.
The security risk depends on what the agent can access and change
John applies Meta's Agents Rule of Two, which considers untrustworthy input, access to sensitive systems or private data, and the ability to change state or communicate externally. His setup works with a proprietary codebase and can change state, while its external communication goes to OpenAI's API endpoint. He considers his case lower risk, but says lower risk does not mean no risk. Each team has to decide whether the permissions fit its system.
Agents.md defines the available subagents and their use
Codex needs instructions in Agents.md explaining how to run each subagent. The file can say when a subagent should run, such as when the user asks for one or when Codex thinks it would help. It also describes which agents exist and what they do. John's example defines agents with a name, a reasoning effort such as light, medium, or high, and a prompt.
The example writes the agent name and user query to files before running one fixed command. Passing those values as command arguments would make the command change on every invocation, which would cause Codex to request permission repeatedly. With a command that stays exactly the same, John can approve it once and choose not to be asked again. This setup does not matter when using the dangerous skip-permissions option, which he says he does not use.
The proof of concept uses small scripts and toy agents
John's proof-of-concept repository contains a 72-line wrapper and a small AgentExecutor Python class. The class starts the child with the required permissions and reasoning effort, then disables the rollout recorder. The demo includes a word-counting agent and a file-writing agent. The wrapper passes the child output to standard out, so the main Codex session can use it like a returned subagent answer.
Codex runs these subagents serially and may take minutes
The demo shows Codex running one subagent at a time rather than asynchronously. John says this is slower than Claude Code and that Codex is slower overall in his experience. A simple file-writing task takes about 40 seconds, while a larger task across a big codebase can take up to 10 minutes or sometimes 20 minutes. His example uses a 600-second timeout, and he says larger jobs may need more time.
"If you're having it do a big task that's going to have it look across a whole codebase and you have a large codebase, it can take up to 10 minutes."12:28
Who should watch
You want subagent-style context management while continuing to use Codex CLI.
Your Codex setup needs to work within the normal sandbox permissions instead of skipping permissions.
You are designing coding-agent workflows and need to understand the approval, timeout, and security tradeoffs.