Sandboxing and command limits

While DataMind Oda works, it runs commands on your computer. Whenever the chat's access mode limits file changes, every command runs inside a file sandbox: it checks the changes the command makes, stops one the mode does not allow, and lets Oda ask you for a single wider retry. This page describes the sandbox levels, what a denial and a sandbox failure look like, and that retry. To choose the mode itself, see Workspaces, files and permissions.

What each level allows

The chat's access mode sets which level a command runs under:

• The sandbox limits file changes only. It does not restrict what a command reads, or what it uses on the network.
• Permission presets covers how the modes are chosen and remembered, and how you switch between them.

When a change is not allowed

When a command tries to change a file the level does not allow, the sandbox stops that change:

• The command's result carries the sandbox note [sandbox: file access denied under <mode> mode], which names the level the command ran under.
• The denied change is not made. Oda reports the denial instead of retrying quietly, and the step records how completely the limits could be applied: in full, or only partly.
• A denial is a sandbox decision, reported separately from how the command ended, so a denied command is not the same as a command failure.
• After a denial, the result adds that this exact command can be retried once with wider access, and that the approval prompt asks you first.
• The same sandbox stops Oda's own file changes; File safety and error messages covers the file side.

The one wider retry

After a denial, and only after one, Oda may retry the exact same command once with wider access:

1. Oda asks for the narrowest wider level that can work, with a one-sentence reason. A retry can only widen: from Read Only to Workspace Write or Full access, and from Workspace Write to Full access.
2. Nothing runs before your answer. If you allow it, exactly that one command runs at the wider level, and the result reports the level it actually ran under.
3. The widening covers that one command: the chat keeps its mode, and the next command that needs it asks again.
4. A refusal is final for that command. Oda does not ask again for it, and continues with the task another way.

When Oda needs more access shows the choices on the approval card and how far a retry can widen.

When the sandbox cannot run

Sometimes the sandbox itself cannot do its job, and Oda does not hide it:

• The sandbox itself fails. If the sandbox fails while a command is starting, the command does not run at all. The result says the sandbox runner itself failed, that the command did not run, and that this is a sandbox problem, not a command failure. Nothing was changed.
• The limits cannot be set up for the folder. Oda does not drop the limits quietly: it says what went wrong and asks before running that one command without restrictions. If nothing can ask you, the command does not run. Command sandboxing and approvals covers those prompts.
• No sandboxing layer. In a setup with no sandboxing layer, a wider retry cannot be requested at all: the request is refused, and Oda continues another way.

What else applies to every command

File limits are not the only limits on a command. The same limits apply whatever the mode:

• A time limit. Two minutes by default; a single command may be given up to ten minutes.
• An output limit. The result keeps up to 64,000 bytes; a larger result is saved in full to a file, up to 64 MiB, and Oda can read it from there.
• A stop grace. A command being stopped gets three seconds to end before it is forced to stop.
• A fresh shell. Every command runs in a fresh shell, and nothing carries over to the next one. For work that needs the same folder and variables across commands, see Persistent shells.

These values can be changed while Oda runs; a change applies to later commands with no restart. The command environment covers where to change them and what every command receives.

On Windows

The levels work on Windows too, with a few things worth knowing:

• Reading is not limited by the levels, but a command under a limited level runs in a more restricted context, and a folder whose access rules do not include that context can fail to open for the command.
• NUL, the system's discard device on Windows, accepts writes in the limited levels, so a command that silences its output keeps working.
• The limits are applied only partly in some ways on Windows; every step records how completely they could be applied. When Oda needs more access lists the Windows effects of the limits.

Questions, answered

What does it mean when a result says the sandbox runner itself failed?

The sandbox could not run the command at all, so the command did not run and nothing was changed. The note adds that this is a sandbox problem, not a command failure: the fault is in the sandbox on this computer, not in the command. Oda can try again, or continue another way.

Why does a command that writes to /dev/null still work in Read Only?

Discarding output changes nothing, so the system's discard device stays writable in Read Only, and commands that send output to /dev/null (or NUL on Windows) keep working. Every file change is still denied.

Does the sandbox limit what a command can read or use on the network?

No. The levels limit file changes only. Reading is not restricted by the mode, and a command's network use is outside the sandbox. The Windows section above has one caveat about reads.

How many times can Oda retry a command the sandbox stopped?

Once. After a denial, Oda may retry the exact same command a single time with the narrowest wider level. If you refuse, or nothing can ask you, that is final for the command: Oda does not ask again, and continues another way.

Can Oda widen access when nothing was denied?

No. The one retry exists for a command the sandbox denied; a wider request comes only after a denial. A command that fits the chat's mode runs without any request, and Oda asks for your answer only when something goes wider than the mode.

How do I know which level a wider retry actually ran under?

After you allow a retry, the result reports the level the command actually ran under.

Why does the step say the limits could be applied only partly?

Some computers apply the limits only partly, and every step records how completely they could be applied. A partial result does not mean the limits were dropped: changes the level does not allow are still denied.

Do Oda's own file changes run under the same limits as commands?

Yes. One file sandbox stops changes under these levels, whether the change comes from a command or from Oda's own file steps. File safety and error messages covers the file side.

Why can a command fail to open a folder on Windows while reading is not limited?

A command under a limited level runs in a more restricted context on Windows. A folder whose access rules do not include that context can fail to open, even though the levels themselves do not limit reading. Every step records how completely the limits could be applied.