Delegation backend: Codex

The Codex backend hands one self-contained task to an unattended Codex session in the chat's workspace. It is one of the delegation backends DataMind Oda can use, and each run returns a single final answer. Choosing and enabling a delegation backend covers the other backends and how the choice is made.

Turn the backend on

Install the backend's bundle in the profile Oda runs. The bundle is titled Codex Subagent and registers under the name codex. Bundles are managed on the Plugins page in the sidebar; see Plugins and bundles.
Add a delegation tool for it in the profile, with its own name, for example subagent_codex. Oda reaches a backend only through a delegation tool you compose: installing the bundle makes the backend available on this computer, but the model can only use what a delegation tool offers. The delegation call itself is on Delegating work to subagents.
Set the backend's values, if you need to: its model, its environment entries and its permission mode. The settings and the permission modes are both below.

Installing the bundle is not the same as connecting it: on its own it starts nothing, signs nothing in and grants no model access. Changes to which bundles a profile carries take effect the next time that profile starts.

The backend's settings

Setting	Default	What it does
`providerName`	`codex`	The name the backend registers under and is reached by.
`model`	unset	Passed unchanged to every run. When it is unset, the backend keeps its own model choice.
`env`	empty	Extra environment entries for the run.
`permissionMode`	`never`	How a run treats the requests it cannot bring to you; the three values are below.
`disposeGraceMs`	`3000`	How long the app gives the run's process to end before it forces it to stop.

A value the backend does not accept is refused when the backend loads, so a mistake shows up before the first delegation.

Choose a permission mode

A delegated run has nobody to ask, so permissionMode decides in advance how it treats requests that would normally go to a person.

Value	What the run does
`never` (default)	Never asks for approval; a step that cannot run returns its failure to the run under the backend's own sandbox.
`approve-for-me`	Routes permission requests through the backend's automatic review, with no person in the loop, and runs in a `workspace-write` sandbox.
`dangerously-bypass-approvals-and-sandbox`	Bypasses approvals and sandbox checks for the run. This value must be selected explicitly.

dangerously-bypass-approvals-and-sandbox turns the checks off entirely, so choose it only when you mean that.

The unattended boundary

A delegated run has no human path: none of the three modes creates an interactive channel, and there is no per-call allow.
Every request the backend raises is answered unattended, following the selected mode.
Each decision is recorded as a fact that names the mode, the request and the outcome, in the form Codex unattended decision (mode: <mode>; request: <request>; decision: <decision>): <reason>.
How a delegated run's permissions start out is on Subagent permissions and sandboxing.

How a run behaves

It works in the chat's workspace: the run's thread is tied to the working directory of the chat the work was delegated from, and the thread is kept for that run alone.
A delegation from a chat without a working directory is refused before the run starts, so give the chat a workspace first.
It starts a fresh process for every run, from the copy of the backend that ships with Oda; it never falls back to an installation of your own.
At startup, Oda introduces itself to the backend as DataMind Oda.
It runs exactly one turn. Nothing carries over to a later run.
A run counts as finished only when it ends with a non-blank final answer; when several answers are marked as the final one, the latest wins. When none is marked, the latest message without a phase marker is used instead.
Only the final answer comes back. Commentary, reasoning, tool activity, error output and workspace changes stay out of the chat.
A run you cancel settles as aborted.
When the delegation tool allows it, run_in_background starts the run as a job and you collect the result later; see Background subagents and job collection.

When a run fails

A failed run reports one safe fact: Product subagent failure (product: Codex; stage: <stage>; category: <category>). The line adds ; HTTP status: <n>, ; exit code: <n> or ; signal: <s> when the run observed one. The stage says where the run stopped, and the category says what kind of problem it was.

Stage	Where the run stopped
`initialize`	Before the run's process was up.
`thread-start`	While starting the run's thread.
`turn-start`	While starting the run's turn.
`turn`	While the turn was working.
`process`	The run's process ended or could not be observed.
`teardown`	While cleaning up after the run.

The run also reports these terminal errors:

subagent-codex: Codex completed without a final answer: the turn ended without a non-blank final answer, so the run settles as an error.
subagent-codex: Codex turn ended with status <status>: <category>: the turn ended in a terminal state other than a clean completion; the status and category say which.

A request from the backend that Oda does not recognise fails the run closed, so nothing is guessed. A context-window overrun is reported as the run hitting its token limit.

The fact is built to be safe to show: raw output, file contents, paths and environment values are kept out of it and stay in the app's own logs. What the chat shows around it, and what to do, is on Subagent failures and diagnostics.

Limits to plan around

No follow-ups: each delegation is one fresh process and thread, with exactly one turn and no continuation, resume or pooling.
No approval path: a run cannot reach you; its requests are answered unattended, following the selected mode (see above).
The Codex state on this computer wins: the run uses the backend's existing account and configuration, and Oda does not discover models, rewrite model names or set fallbacks.
No wait limit: there is no wall-clock timeout; a run keeps going until it finishes, fails or is cancelled.
No undo: changes a run makes on the computer are not rolled back when it fails or is cancelled.
Only the final text is kept: commentary, reasoning, tool activity, error output and workspace changes are never part of the result.
No per-delegation extras: asking for a child model, a structured-output schema, a persona, a tool filter or a depth budget is refused before the run starts.

Questions, answered

How do I enable the Codex backend?

Install its bundle in the profile Oda runs, then add a delegation tool for it with its own name, for example subagent_codex. Installing the bundle makes the backend available on this computer; Oda reaches it only through a delegation tool you compose. Choosing and enabling a delegation backend covers the general steps.

Which of the three modes should I choose?

Keep never, the default, unless you have a reason to change it: Codex never asks for approval, and a step that cannot run returns its failure to the run under the backend's own sandbox. Choose approve-for-me when requests should go through the backend's automatic review, with the run limited to a workspace-write sandbox. Choose dangerously-bypass-approvals-and-sandbox only when you deliberately want approvals and sandbox checks skipped; it is never selected for you.

Can a Codex run ask me for approval?

No. No mode creates a way to reach you: a run cannot ask you directly, and there is no per-call allow. Every request is answered unattended, following the selected mode, and each decision is recorded.

Why was a Codex delegation refused before it started?

Usually one of two reasons. The chat may have no working directory, so the run has nowhere to work. Or the delegation asked for an extra this backend does not carry, such as a child model or a structured-output schema. In both cases nothing was started. Give the chat a workspace, drop the extra, or use a backend that supports it.

Can I send a follow-up or resume a Codex run?

No. Each delegation is one fresh process and thread, with exactly one turn and no continuation, resume or pooling. When a task needs back-and-forth, use a backend that supports continuable subagents; Continuable subagents covers them.

Does the run use the Codex state on my computer?

Yes, and it is used as it is. The run relies on the account and configuration Codex already has on this computer; Oda does not discover models, rewrite model names or set a fallback. The run itself starts from the copy that ships with Oda, never from an installation of your own.

How do I change the model a Codex run uses?

Set the model value in the backend's settings; it passes unchanged to every run. Leave it unset and the backend keeps its own model choice. A delegation that names a child model of its own is refused for this backend before the run starts; Choosing the model for a subagent covers that feature where it is available.

Is a Codex run stopped if it takes too long?

No. There is no wall-clock timeout: a run keeps going until it finishes, fails or is cancelled. A run you cancel settles as aborted.

What does `Product subagent failure (product: Codex; ...)` mean?

It is the safe failure fact for a delegated run. The line names the stage where the run stopped and a category, and adds an HTTP status, an exit code or a signal when one was observed. The full list of what a failure can read like, and what to do next, is on Subagent failures and diagnostics.

What does `subagent-codex: Codex completed without a final answer` mean?

The turn finished, but Codex produced no non-blank final answer, so the run settles as an error instead of a success. Read the diagnostic for where it stopped, and delegate again if the work still matters.

What does `subagent-codex: Codex turn ended with status <status>: <category>` mean?

The turn ended in a terminal state other than a clean completion. The status and category name what happened; a context-window overrun, for example, is reported as the run hitting its token limit.