Delegation backend: Claude Code

Claude Code is one of the delegation backends DataMind Oda can hand a task to: it delegates one self-contained task to an unattended Claude Code session in the chat's workspace. Use it for a task that can run to the end on its own; 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 Claude Code Subagent and registers under the name claude-code. 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_claude_code. 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`	`claude-code`	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. Credential-shaped values from this computer are removed first, and your entries are added on top.
`permissionMode`	`dontAsk`	How a run treats the requests it cannot bring to you; the five 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
`dontAsk` (default)	Denies operations that are not already authorized instead of prompting.
`acceptEdits`	Accepts the edits a run makes.
`auto`	Decides through the backend's own classifier.
`plan`	Runs in planning mode, denies execution approval, and returns the completed plan as the final answer.
`bypassPermissions`	Explicitly sets the backend's dangerous confirmation and bypasses its permission checks.

bypassPermissions is the one value that turns the checks off entirely, so choose it only when you mean that. How a delegated run's permissions start out is on Subagent permissions and sandboxing.

The unattended boundary

The run has no human path: permission prompts are denied, interactive input requests are declined, and blocking dialogs are cancelled.
The tool a run would use to ask you a question is switched off, and in plan mode the run cannot leave planning early: the plan is the answer.
A run that asks anyway is told This unattended Claude Code subagent cannot request human approval.
Every decision is recorded as a fact that names the mode, the request and the outcome, in the form Claude Code unattended decision (mode: <mode>; request: <request>; decision: <denied|declined|cancelled>): <reason>.

How a run behaves

It works in the chat's workspace. A delegation from a chat without one is refused before the run starts, so give the chat a workspace first.
It follows the Claude Code settings already on this computer, read from that workspace. Those settings are authoritative: Oda does not copy, filter or change them, and it does not touch your sign-in state.
It runs the copy of the backend that ships with the app and never falls back to an installation of your own.
A run counts as finished only when it reports success with a non-blank final answer; when a run reports several, the latest one wins.
Only the final answer comes back. Reasoning, tool traffic, error output and workspace changes stay out of the chat.
A run you cancel settles as aborted, with no diagnostic.
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: Claude Code; stage: <stage>; category: <category>). The line adds ; exit code: <n> or ; signal: <s> when the run's process ended. The stage says where the run stopped, and the category says what kind of problem it was.

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

Category	What it points at
`limit`	The run reached one of its own limits, such as its turn count or its budget.
`product-error`	The session reported an execution error.
`invalid-result`	The session ended without a usable final answer.
`process`	The process, not the answer, was the problem.
`unknown`	No more specific category applied.

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 run, with no continuation, resume, pooling, progress or persistence.
No approval path: anything that needs a person is denied (see above).
The settings on this computer win: the run reads them and Oda does not override them.
No wait limit: there is no wall-clock timeout, so a run keeps going until it finishes or is cancelled.
No undo: workspace changes a run makes are not rolled back when it fails or is cancelled.
Only the final text is kept: reasoning, tool traffic, 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 for this backend is refused before the run starts.

How this backend compares with the others is on Choosing and enabling a delegation backend.

Questions, answered

How do I turn the Claude Code backend on?

Install its bundle in the profile Oda runs, then add a delegation tool for it with its own name, for example subagent_claude_code. 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 permission mode should I choose?

Keep dontAsk, the default, unless you have a reason to change it: it denies anything a run is not already authorised to do instead of prompting. Use plan when you want a plan returned instead of the work being done, and choose bypassPermissions only when you deliberately want the run to skip the backend's permission checks. auto decides through the backend's own classifier, and acceptEdits accepts the edits a run makes.

Can a run ask me a question while it works?

No. Delegated runs have no human path: the question tool is switched off, permission prompts are denied, interactive input requests are declined and blocking dialogs are cancelled. A run that asks anyway is told This unattended Claude Code subagent cannot request human approval. See Subagent permissions and sandboxing.

Why was a delegation refused before it started?

Usually one of two reasons. The chat may have no workspace, 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.

What happens to files the run changes?

They stay. The backend has no side-effect rollback, so changes a run makes are not undone when it fails or is cancelled, and its workspace changes are never part of the result that comes back to the chat.

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

No. Each delegation is one fresh run, with 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 Claude Code settings on my computer?

Yes, and they are authoritative. The run reads the backend's own settings (user, project and local) from the chat's workspace, and Oda does not copy, filter or change those files. The run uses the copy that ships with Oda, never an installation of your own from the command line.

How do I change the model a 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.

Can a run go to the background?

Yes, when the delegation tool allows background runs: the delegation returns a job id instead of waiting, and you collect the result with the job tools. Background subagents and job collection covers starting, collecting and stopping such runs.

Is a run stopped if it takes too long?

No. There is no wall-clock timeout: a run keeps going until it finishes, or until it is cancelled. A cancelled run settles as aborted, with no diagnostic, and its process is cleaned up.

What does `Product subagent failure (product: Claude Code; ...)` 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 exit code or signal when the process ended. The full list of what a failure can read like, and what to do next, is on Subagent failures and diagnostics.