Permissions and approvals

DataMind Oda checks every step before it runs: the file sandbox limits where it may change files, and an approval step decides which steps need your answer first. This page is the reference behind those checks. It covers where the approval step sits, what asks before it runs, what a mode bundles, who may answer, and what happens when nothing can.

How a step passes the checks

Every step Oda takes runs through the same stages, in order:

1. The checks that can refuse the step run first, before anything is executed.
2. The approval step asks once when the step needs an answer. Nothing runs while the request waits.
3. The step runs under the limits of the chat.
4. The result is recorded and returned, whether the step ran, was denied, or never started.

Two rules make the chain safe by default:

• One answer, one step. The approval step asks once for the one step it is about, and every answer applies to that step only. Nothing is remembered between requests, so a later step that needs approval asks in a new request. Approvals covers the card and its answers.
• No answer means no. If a request cannot reach anyone, or nothing answers it, the step does not run. There is no default approval and no silent fallback: the request chain fails closed, so a step that no one answered is never approved on your behalf.

What asks before it runs

• The library requests ask through the same approval step as a step beyond the mode, so the answers work the same way: one answer, one change. Each one shows the exact change first, which is why a skill save lists its files (Create and install skills) and a scheduled-task change lists its settings.
• Hooks and scheduled tasks stay with the main conversation: a subagent or teammate cannot create or change them, so these changes are prepared and approved in the main chat. See Hooks from chat and Schedule recurring tasks.
• A plan is presented only in plan mode, and the review waits until you decide; Plan mode covers the card and what each answer does.
• In a Full access session, a library write is saved without a prompt, and Oda records it: The session has Full access, so it was written without an approval prompt. When approval prompts are off in a session that does not have Full access, the request is refused instead, and nothing is saved.

What a mode bundles

A permission preset is two settings travelling together: how far Oda may change files, and whether a step that goes wider asks you first. Switching the preset sets both at once, so the mode shown in a chat names both its file limits and its approval policy.

• Read Only and Workspace Write keep the prompts on, so a step beyond the mode waits for your answer.
• Full access has no file limits and the prompts are off. It is offered only while your DataMind account allows it.
• Auto review (experimental) also runs without the file limits, and the prompt is replaced by a review of each call: the reviewer allows or denies, a denied call never runs, and an unclear or failed review denies, because the check fails closed. Auto review covers what the reviewer weighs.

When a chat's file limits and prompt settings match no preset, the control shows Custom; choosing a preset moves the chat back onto one. Access modes and approvals covers the presets behind the modes, and Permission presets covers switching and remembering them.

Who may answer

• You do, in the chat. A request waits for your answer, and nothing else can answer on your behalf; an answer that arrives after the request was stopped is discarded.
• A subagent cannot ask at all. A delegated run has no route to you, so a step that would need your answer is refused inside the run and reported back, and an attempt to widen access is rejected without asking anyone. Subagent permissions and sandboxing covers the details.
• An unattended run records instead of asking. A scheduled run has no one to answer, so a step that needs approval does not run, the rest of the run finishes, and the run's history lists what needed approval.
• Some requests accept only your own instruction. Starting, editing, pausing or resuming a goal works only when the request comes from you directly: a helper's report, or a brief started from a suggestion, is refused as the wrong source. Marking a goal met or blocked may also proceed from the goal's own running round, and a goal is not reported blocked until the same obstacle has survived three rounds in a row (three is the default). Goals covers the goal's surfaces.

When a step is denied

• The file sandbox stops a change outside the allowed limits, and the denial names the mode it ran under, in the form [sandbox: file access denied under <mode> mode]. The denied change is not made. Oda reads the denial, continues with what it may do, and can ask to retry the exact step once with wider access, naming the narrowest mode that can work. Command sandboxing and approvals covers the retry.
• A retry inside a subagent is refused without asking anyone, and the refusal is reported back to the chat.
• When the file limits cannot be applied to a folder at all, Oda does not run the step with the limits quietly dropped: it asks before running that one step without restrictions, and where nothing can ask, the step does not run.
• In Auto review, a denial is not a question: a call the reviewer denies does not run, and the step is recorded as a rejection. Auto review covers the reviewer's rules.

Questions, answered

Can an approval pass by default when nobody answers?

No. A step with no answer does not run: the request chain fails closed, so nothing is approved silently, and a request that cannot be delivered leaves the step undone.

Why does saving a skill or a hook ask, even when the chat's mode allows the change?

Because a library write is not judged by the mode's file limits: it asks through the approval step on its own, whatever the mode, and only a Full access session skips the request.

What does the request show before a library write?

For a skill, the complete file list: folder, files, total size, and anything left out with its reason. For a hook, the exact event, matcher, command and file, as Before: and After:. For a scheduled task, the exact settings and the prompt. Nothing is saved until you approve.

Who can answer an approval request?

You, in the chat. Nothing else can answer for you: a subagent cannot ask at all, and an unattended run gets a refusal recorded instead of an answer.

Can a helper start, change or pause my goal?

A helper cannot start, edit, pause or resume a goal: those accept only your own instruction given directly, and a helper's report or a started brief is refused. Marking a goal met, or blocked, may also come from the goal's own round.

How soon can a goal be reported blocked?

Not on the first obstacle: a goal is not reported blocked until the same obstacle has survived three rounds in a row, so a single failed round does not end it. Three is the default minimum.

Does a sandbox denial stop the run?

No. The denied change is not made, and Oda reads the denial and continues with what it may do; it can also ask to retry the exact step once with wider access.

Why did a step run without asking me?

Because it stayed inside the chat's access mode, where no approval is needed, or because the session runs with approvals off (Full access, and Auto review for its reviewed calls). In a session with approvals off, an operation that would need your answer is refused rather than run, so nothing is approved on your behalf.

What happens to a library write in a session with Full access?

It is saved without a prompt, and Oda records it: The session has Full access, so it was written without an approval prompt. When approval prompts are off in a session that does not have Full access, the request is refused instead, and nothing is saved.