Let a coordinator approve its workers' permission requests (opt-in)

[ycmjason]

The problem

A coordinator thread can start a worker in a supervised mode (delegate_task or t3_thread_launch with runtimeMode: "approval-required"), but it can't answer that worker's approval requests. t3_pending_request_list leaves approvals out, and t3_pending_request_respond can't approve or deny them. Every request waits for the user on the worker's thread, which is often hidden (#15082, #14416).

That leaves two options, and neither works well:

• Full access plus prompt rules ("only load these tools", "don't push"). Nothing enforces them. The coordinator can only check the worker's activity log afterwards.
• Supervised. The rules are enforced, but I have to approve every git status by hand, which defeats the point of delegating.

What I'm after: a strong model coordinates and cheaper models do the work. The coordinator decides on each gated action, knowing what the task is. For example, it allows git diff and denies git push, allows edits under src/ and denies .env, and denies a computer-use call that would drive my own machine instead of a sandbox. Cheap workers become safer to run unattended, and I only see the decisions the coordinator escalates.

Proposal

1. Opt in per launch. Add an option on delegate_task and t3_thread_launch (for example approver: "user" | "coordinator"). The default stays user, so nothing changes unless it's set.
2. Delivery. The worker's approval requests reach the coordinator through the notice path from fix(server): tell parents when a delegated task is waiting for input #13343. For launched threads, that needs the coordinator link proposed in Let an orchestrator thread hear from its workers, and pass their questions to the user #17212. They also show up in t3_pending_request_list and t3_pending_request_read with the full request: command, file and diff, or tool name and arguments.
3. Answering. t3_pending_request_respond accepts approve or deny for these requests, with an optional reason the worker can see. I'd leave "always allow for this session" out of scope at first.
4. Guardrails.
   • Only the worker's own coordinator can answer, not just any thread.
   • The coordinator can't approve beyond its own runtime mode.
   • The worker's timeline records each decision and who made it.
   • The user can still answer in the worker's thread, and whichever answer arrives first wins.
   • A user setting can turn the feature off entirely.

This doesn't add any capability the coordinator lacks today. A full-access coordinator can already start the same worker with runtimeMode: "full-access". Approving one call at a time is strictly narrower than that, and it is enforced, unlike prompt rules.

Related

• Let an orchestrator thread hear from its workers, and pass their questions to the user #17212 deliberately leaves out "auto-approving anything on the user's behalf". This raises it separately, as an opt-in where the user still chooses who approves for each launch.
• Read-only runtime mode for delegated tasks (Codex: read-only sandbox, approval never) #15184 (read-only mode) covers pure review. This covers mixed work, where some writes are fine and others aren't.
• It builds on fix(server): tell parents when a delegated task is waiting for input #13343 for delivery.

Questions for maintainers

• Is a coordinator approving on the user's behalf acceptable when it's opted into per launch?
• Should the opt-in sit on the launch call, or only in a user setting the agent can't change?