While DataMind Oda works on a task, it sometimes runs a command on your computer: a small program in Bash or PowerShell that starts, does its work, returns its output, and ends. This page covers how those commands run and how to read what comes back. How each command appears as a step in the chat is described in Commands Oda runs.
When a command ends, its result carries the output, and a short note says how it ended. The notes you may see:
| Note | What it means |
|---|---|
[exit code: N] | The command finished and reported this code. Zero means it succeeded; any other number means it reported a failure. |
[killed by signal: X] | A signal ended the command instead of a normal exit. |
[timed out after <n>ms] | The command reached its time limit before it finished. |
[stopped: <reason>] | The command was stopped from outside, and the reason says why. Oda reads the note as a stop, not as a failure of the command, so it does not retry the command on its own. |
(no output) | The command returned nothing. |
[output truncated; full output: <path>], or [some output was dropped from memory; full output: <path>] when the app had to drop part of the output. The full text is saved to the file the note names; ask Oda to open it, or to search inside it, when you need the rest.When a command is still running at its time limit, Oda does not kill it. The command moves to a background job and keeps running while the chat carries on.
[still running after <n>ms; moved to background job <id>], with the note that the command keeps running, that Oda is told when it finishes, and that Oda reads newer output with job_output and stops the job with job_kill.started background job <id>.finished [status: completed, exit code: 0], and Oda collects what came back. A later read returns only newer output; what was already collected is not repeated.belongs to another session.run_in_background is disabled for this deployment. Ask Oda to run the command in the foreground instead; its time limit applies as usual.[exit code: 1] and no signal; treat it as an interruption, not a failure the command reported.param(. or #requires, cannot run as written; it works when wrapped in a block or kept in a file and run from there.Yes. Every command is a fresh run, so the folder it ran in and the variables it set do not carry over to the next command. For a task where each command should build on the one before, Oda keeps a shell alive instead; see Persistent shells.
Every command gets a time limit; the default is two minutes. Oda can set a longer limit for a command, up to ten minutes, and the limits applied to commands are described in The command environment. A command that reaches its limit is not killed: it moves to a background job and can keep running there.
Oda does not kill a command at its time limit. Instead, it hands the command over to the background as a job, so the command keeps running while the chat carries on. The step reports the hand-over, and Oda is told when the job finishes.
Ask Oda for its output. Oda reads newer output with job_output, and when the job finishes the notice reads finished [status: completed, exit code: 0]. A read returns only what has arrived since the last one.
Press Stop in the message box while the step runs, or ask Oda to stop the background job with job_kill. A command stopped from outside reads [stopped: <reason>], with the reason saying why, and Oda does not retry it on its own.
No. A background job belongs to the chat that started it, and it is read from there. A read from another chat is refused, and Oda reports belongs to another session.
Background runs are switched off in this installation. The option is not offered, and a request that still asks for one is refused with run_in_background is disabled for this deployment. If the background support is not loaded at all, Oda reports that background jobs are unavailable. Ask Oda to run the command in the foreground instead.
On Windows, a command that is force-stopped reports [exit code: 1] and no signal. That is how an interruption shows there, not a failure that the command reported.
Before a command runs, Oda sets up its text handling, and that setup comes before the command itself. A first statement that must come first, such as param(. or #requires, cannot run that way; the script works when kept in a file and run from there, or wrapped in a block.
The command produced more output than the result keeps. Oda saves the full text to a file, and the note names it: the note says the output was truncated, or that some of it was dropped from memory. Ask Oda to open the file, or to search inside it, when you need the missing part.
tool call aborted mean?The step was stopped before it could finish, so it has no result, and the command does not continue. Ask Oda to run it again if you still need it.