Keep delegated work within scope
Delegation copies your access into a child conversation. You can make that smaller, but you cannot make it larger than your own.
What a child inherits
A child normally starts a fresh conversation and cannot see this one, then and later. It receives the caller's Projects, tools, permissions and read-only state, and it works with your model by default. Nothing about a different model, a fork or a custom sub-agent type adds access.
A child also has no personal memory of yours. It works from the task you gave it and whatever you asked it to fork from.
Narrow a child
Ask for a narrower child when the task does not need everything:
- name only the tools the task needs;
- ask for read-only work when the child should only investigate;
- pick a read-only sub-agent type such as
exploreorplan; - continue an existing child instead of starting another, so its findings carry on.
Check a custom type's own restrictions before you use it. The built-in explore and plan types are read-only, and a plan child returns its proposal as a reply instead of writing a file. The review type inherits your tools but does not change a repository.
If you asked for a read-only child yourself, you can grant it write_access: true later, and only from the same account. A read-only limit that came from Plan mode or from the child's type cannot be lifted that way.
Read-only is not a sandbox
A read-only child loses its write tools, and common destructive shell commands are blocked. Shell redirection can still write files the account can reach, so treat read-only as a permission limit, not an isolated filesystem.
When work needs its own filesystem, run it in a managed Project environment instead. See Projects overview.
Admin: Share conversation context under Settings →
<assistant name>AI → Limits and connection retries → Edit limits makes a new child start from this conversation by default. A delegation that sets forking itself is unaffected.
A child that started as a fork shares the parent prompt and tools. It shares the provider cache only when it runs on the same provider and model.
After a restart
Chetty tries to recover unfinished delegated and workflow work after a restart. Each step of a workflow receives a short handover from the steps directly before it.
If the required access cannot be verified, Chetty stops or parks that work instead of replaying it with wider authority. Check the conversation for the final state before repeating the work.