DataMind Oda can hand part of a task to a subagent, and a subagent works on its own: it may run in the background while the chat carries on, with nobody at the keyboard to answer a question. Its permissions are settled when it starts rather than while it runs: it works inside the limits set for it, it never asks you for approval, and it cannot widen its own access. How delegation itself works is in Delegating work to subagents; the access modes are in Workspaces, files and permissions.
When Oda hands work to one of its own subagents, the subagent's permission state is fixed at that moment, taken from the chat that starts it:
A backend that runs its own agent product, such as Claude Code or Codex, sets permissions from its own settings instead; Choosing and enabling a delegation backend covers the targets.
In the chat itself, Oda asks when a step needs more than the mode allows, for example a wider file change, and the shared browser asks before it reads a site (Command sandboxing and approvals, The browser in Oda). A subagent has none of those dialogs: no question of its own can reach you.
For Oda's own subagents, the file sandbox works as it does in a chat:
[sandbox: file access denied under <mode> mode], naming the mode the subagent ran under, for example [sandbox: file access denied under read-only mode]. The change is not made.the user rejected escalating this operation to "workspace-write".was fixed when you were started and cannot be widened from inside this session; when access is missing it should state the limitation in your reply so the delegating agent can handle it. So the limit comes back to your chat as a report, and the chat can handle the step from there.Messages a run can fail with are collected in Subagent failures and diagnostics.
The state fixed for it when it started. Oda takes it from the chat at that moment: a chat in Auto review or Full access passes that level on, a mode you switched, such as Read Only, bounds the subagent the same way, and with nothing chosen the subagent runs under the app's normal default. None of it is the subagent's own choice.
No. A subagent cannot bring an approval question to you, so there is no step for you to approve: what it is not already allowed to do is refused inside the run. To let such work through, decide the access before delegating: set the chat's mode, then start the subagent. The dialogs you do see in a chat, such as a request to retry a step with wider access or a site question for the browser, belong to the chat itself.
No. An attempt to retry a blocked step with wider access comes back rejected, without anyone being asked: the user rejected escalating this operation to "workspace-write". Each subagent is also told at its start that its scope cannot be widened from inside it.
Because no one is asked: a subagent cannot reach you for approval, so a widening attempt is decided automatically and comes back as that rejection. If the work needs more access, set the chat's mode first and start a new subagent.
Your chat can ask you for more; a subagent cannot, so it stays strictly inside the state fixed at its start. A change that state does not allow is stopped by the file sandbox and reported as [sandbox: file access denied under <mode> mode]; the blocked change is not made. Leave that step to the chat, which can ask you, or set the mode and start a new subagent.
No. The state is fixed when the subagent starts; a change afterwards stays with the chat and reaches only subagents you start later.
No. A resumed subagent comes back with the state it started with, so a widening made afterwards does not reach it. Set the mode first and start a new subagent for that work; what resuming is and when it happens is in Subagent settlement and results.
No. The rules on this page describe Oda's own subagents. A backend that runs its own agent product, such as Claude Code or Codex, answers permission requests inside that product from its own settings; nothing there reaches you either, and the target's page has the values. Choosing and enabling a delegation backend compares the targets.
Requests answered without you are recorded as facts that name the request and the outcome, so a subagent's allowances and refusals can be traced; a failed run's diagnostic can carry the latest one. Each backend has its own form of the fact, shown on its page.
[sandbox: file access denied under read-only mode] mean?The subagent tried to change files that the mode fixed for it does not allow (here, the Read Only mode). The change was not made, and the marker names the mode the subagent ran under. A subagent cannot widen its way past it: such a retry is rejected, and the subagent is told to report the limit instead.