Some steps need more access than the chat's mode allows. DataMind Oda reports the denial, and can ask you to allow a single retry with wider access. This page covers that request and what happens when the limits cannot be set up on your computer. How the modes work, and how to change them, is in Workspaces, files and permissions.
A step that tries to change files the mode does not allow is stopped by the file sandbox:
Nothing runs before you answer a request. For the step kinds themselves, see Command sandboxing and approvals for commands and File safety and error messages for file changes.
A request for more access uses the same card as other approvals:
| Choice | What it does |
|---|---|
| Allow once | Runs exactly that one step with the wider access. |
| Reject | The step does not run. |
| Reject with instructions… | The step does not run, and your note tells Oda what to do instead; the note is passed on with the rejection. |
Your first task lists the choices and what each answer does; Approvals covers the card itself.
A retry can only widen, and only as far as it needs:
| From | A retry can widen to |
|---|---|
| Read Only | Workspace Write or Full access |
| Workspace Write | Full access only |
On some computers the file limits cannot be applied to your folder, for example when the system refuses the permission change they need, or when nothing on the computer can apply them. Oda does not drop the limits quietly. It says what went wrong and asks before running the step without restrictions:
DataMind Oda can't limit writes to <folder>.Run this <step> without restrictions?
Some setups cannot run the limits at all. Oda will not run the step without them: it explains what is missing, and the step does not run. A folder you own, Full access where it is offered, or another approach can move the task forward.
On Windows, a few effects of the limits are worth knowing:
A step tried to go beyond the chat's access mode, for example changing a file outside the workspace or running a command that needs more rights. It was stopped, and Oda can ask to retry that one step with wider access. Nothing runs before you answer.
Only wider, and only as far as it needs: from Read Only it can ask for Workspace Write or Full access; from Workspace Write, only Full access. A step that stays inside the chat's current mode needs no request.
One step. The widening covers exactly that step, the chat keeps its access mode, and the next step that goes wider asks again.
The step does not run. A rejection ends it for that step, and instructions you add are passed on so Oda can work another way. If the request is cancelled or nothing can ask you, nothing is approved, and a late answer is discarded.
On some computers the limits cannot be applied to the folder, for example when the system refuses the permission change they need. Instead of dropping the limits quietly, Oda says so and asks first. If you allow it, that one step runs without restrictions; if you decline, it does not run.
Some setups cannot run the limits at all. Oda will not run the step without them: it explains what is missing, and the step does not run. A folder you own, Full access where it is offered, or another approach can move the task forward.
Some protections are partial (a hard link still counts as the same file, and a limited command is not separated from the app's console), some administrative and inventory commands do not work in limited modes, some commands that start another process through a pipe are blocked, and PowerShell runs in a restricted language mode under Read Only.
The step shows a short note that the change was denied, and the note names the mode the step ran under. The denied change is not made. Oda then either asks to retry once with wider access or continues with the task another way.