Command environment and containment
While DataMind Oda works on a task, it runs commands on your computer, and every other program it starts uses the same machinery: the language servers it starts for code navigation, the shells kept alive between commands, and the helper programs behind delegated work. This page covers what those programs see of your settings, how a command is started and held together, and what happens to it and its output when the work ends.
What Oda runs, and under what limits
- The commands in a chat are one surface of this machinery; Shell commands covers how they run and how to read them. The others are Language servers for code navigation, the Persistent PowerShell shell kept between commands, and the separate programs behind Subagent backends.
- Every program starts the same way, and each command is held together with everything it starts, so the whole piece of work can be stopped as one.
- Commands follow the chat's access mode. A command that tries to change files beyond what the mode allows is stopped by the file sandbox, and the attempted change is not made; Command sandbox and approvals covers the denial and the one wider retry you can allow, and Workspaces, files and permissions covers the modes themselves.
What a command sees of your environment
- Each command starts from a cleaned copy of your computer's settings: names that look like credentials, such as keys, passwords, secrets and tokens, are left out along with Oda's own working values.
- The cleaning reads names, not values, so treat it as a guard and not a guarantee: a secret kept in a variable with an unrelated name can still reach a command.
- When a step deliberately hands a value over, that value still arrives, alongside the cleaned copy.
- Everyday facts arrive unchanged: where programs live, your home folder, your language and text settings, and your proxy settings; Network proxies in Oda covers how a proxy reaches the programs Oda runs.
How a command starts
- A start is fully explicit: the program, its arguments, the folder it runs in, the settings it receives and how its input and output are wired are all supplied; nothing is filled in silently.
- A request that names no program is refused before anything starts.
- The program must resolve. A full path is used as given; a bare name is looked up on the program search path, with the Windows endings
.COM, .EXE, .BAT and .CMD among the names tried; a relative path is refused. A name that cannot be found is refused with was not found on PATH, a file that cannot be run with is not an executable file, and nothing runs.
- On Windows, a program that cannot start reports
spawn <program> <code>, with a short code such as ENOENT. A failure with no known short code reports spawn <program> UNKNOWN (Windows error <number>); the number, and any text after it, carries the system's own reason, for example a security policy that blocks the program.
How a command is held and stopped
- Each command gets a managed range: the program, and everything it starts, move together, and stopping the work stops the whole range. Oda asks the processes to stop first and forces anything still running after a short grace period. Process containment and cleanup covers how the range is owned on each kind of computer.
- On Windows, the programs Oda starts for commands, and its own stop helpers, start with their windows hidden, so a background command never flashes a console window or takes focus from what you are doing.
- Oda prefers the strongest containment your computer can offer, and re-checks that support at each start. When it is unavailable, the command runs under a weaker fallback, and Oda records one note per app run, naming the reason.
- Oda never starts a command a second time through the fallback: once the stronger path may have started it, it is not replayed.
What is kept of a command's output
- When more output arrives than the run keeps, the end of the output is kept, because errors and results cluster there, and the result is marked as cut; Result limits and spill files covers the notes a cut carries and how each kind of result is shortened.
- With a size set for the stream, the command's complete output is written to a private file while it runs: a folder only your user account can open, with randomly named files. Oda does not delete the file when the command ends, so the output can still be read back afterwards; Large results and spill files covers where such files live and when they are cleared up.
- A read that starts before the part still held comes back marked incomplete: Oda returns what is left and says the read is lossy, so treat what you get as partial.
- A command's ending is recorded as its exit code, or as the signal that ended it; nothing else is added to that record.
When Oda stops or closes
- When you quit Oda, or when it exits through an error it can catch, it stops the commands it still manages before leaving, so they do not keep running on their own.
- A forced kill, an out-of-memory stop, or a crash below the app cannot be caught from inside Oda; those cases are left to the operating system, or to an outside supervisor, to clean up.
- A private control channel Oda uses to manage a running command is reserved: nothing outside Oda can set it up, and an attempt to supply it is refused before the command starts.
Questions, answered
Does a command see my passwords and keys?
No. Each command starts from a cleaned copy of your computer's settings, and names that look like credentials, such as keys, passwords, secrets and tokens, are left out, as are Oda's own working values. The cleaning reads names and not values, so a secret kept under an unrelated name is not covered; when a step deliberately hands a value over, it still arrives.
Which programs does Oda start on my computer?
The commands it runs in a chat, the language servers it starts for code navigation, the shells it keeps alive between commands, and the separate programs behind delegated work. They all start through the same machinery, and each one is held together with everything it starts.
How is a command different from a terminal session?
A command runs once: it starts, does its work, returns its output and ends. A terminal session is an interactive shell that stays open while Oda types into it and reads what comes back; Terminal sessions covers those.
Why did a program fail to start on Windows?
A program that cannot start reports spawn <program> <code>, with a short code such as ENOENT. A failure with no known short code reports spawn <program> UNKNOWN (Windows error <number>); the number and any text after it carry the system's own reason, for example a security policy that blocks the program. Nothing ran.
When a command is stopped, does everything it started stop too?
Yes. A command and everything it starts are held as one managed range. Stopping the work asks the whole range to stop, and forces anything still running after a short grace period.
Can I still read a command's full output after it ends?
Yes. When the complete output is written to a file while the command runs, the file stays after the command ends, so Oda can read it back or search inside it when you ask. It sits in a folder only your user account can open; Large results and spill files covers where such files live and when they are cleared up.
Why did part of an earlier output come back incomplete?
The run keeps a window of the most recent output. Once older output slides out of that window, a read that starts from before it cannot return the missing part, so Oda returns what is still held and says the read is lossy. Treat the result as partial.
What happens to running commands when Oda closes or crashes?
When you quit Oda, or when it exits through an error it can catch, it stops the commands it manages before leaving. A forced kill, an out-of-memory stop, or a crash below the app cannot be caught from inside Oda, so those cases are left to the operating system, or an outside supervisor, to clean up.
Could my command be started a second time when containment falls back?
No. Oda never starts a command a second time through the weaker fallback: once the stronger path may have started it, it is not replayed. A command that ran under the fallback ran that way from the start.