create_thread drops scoped user-consent provenance and lacks a parent-bound return channel

Codex app version

26.825.51511 (build 7377)

Subscription

Not checked; this appears unrelated to subscription tier.

Platform

Apple Silicon macOS (Darwin 25.6.0 arm64)

What is the issue?

Standalone tasks created by another Codex task with create_thread do not retain verifiable provenance for scoped user consent carried in the creation prompt. They also do not appear to receive a parent-bound capability for returning a result to the task that created them.

This is adjacent to, but narrower than, #33282. That issue covers inheritance of the sandbox and approval-policy tuple. This report concerns two additional capabilities needed for safe delegation even when fail-closed behavior is working as designed:

1. Scoped action consent provenance. A user directly approved a narrow class of actions in the parent task (specific test runs and reset/deletion of service data belonging to the delegated task's isolated lane). The parent created a visible tracked task and repeated that exact scope in its create_thread prompt. When the child requested the exact destructive action, the approval reviewer correctly refused to treat prompt text as direct user consent. After the user repeated the same approval directly inside the child task, the same action was allowed.

2. Parent-bound result delivery. A child instructed to return a sanitized status update to the exact task that created it can be prevented from using send_message_to_thread, because the recipient was supplied by orchestration text rather than directly authorized by the user in the child. Sanitizing content addresses disclosure content, but cannot establish recipient authorization.

The current behavior is security-preserving, but it leaves no typed, verifiable way to delegate narrow consent or to send a result back to the creator. Long-lived visible staff tasks can therefore deadlock until the user manually visits each task and repeats the same approval.

Steps to reproduce

Scoped consent

1. In a parent Codex Desktop task, have the user explicitly approve a narrow action scope, for example: running a named test class and resetting only the delegated task's isolated service-data directory.
2. From that parent, call create_thread to create a visible tracked task. Include the exact approved scope in the child prompt.
3. In the child, request escalation for an action inside that exact scope.
4. Observe that the approval reviewer does not accept the copied prompt text as direct user consent.
5. Have the user repeat the same approval directly in the child task.
6. Retry the same action and observe that it can proceed.

Parent return channel

1. Create a child task with create_thread and instruct it to send a sanitized completion summary to the exact creating task.
2. In the child, call send_message_to_thread for that parent task.
3. Observe that the child may lack recipient authorization even though the destination is its creator.

What did you expect to happen?

create_thread should either support a typed, auditable delegation envelope or clearly surface fresh approvals in the child. A safe typed design could include:

• an immutable createdBy / parentThreadId relationship;
• a consent-grant reference tied to the original direct user event;
• grants restricted by action, resource/lane, destination, expiry, and revocation;
• a notify_parent capability whose only destination is the creating task;
• enforcement that prevents the child from broadening any inherited grant.

This should not blindly copy all parent permissions. If scoped delegation is intentionally unsupported, the UI/API should instead pause creation or surface the needed approval directly to the user, and documentation should state that action-specific consent does not cross standalone task boundaries.

Additional information

True subagents and standalone tasks have different semantics: documented subagents inherit the parent's sandbox policy and permission mode, while create_thread creates a separate tracked task/chat. The separate-task model is useful for visible, long-lived delegated roles, but currently lacks an equivalent safe mechanism for narrow consent provenance and creator-only result delivery.

Related: #33282 (create_thread does not inherit auto-approval mode for worktree tasks).

No project names, filesystem paths, task IDs, or sensitive payloads are included in this report.

Start with the create_thread and send_message_to_thread entry points, then review the documented subagent semantics and related issue #33282. Done means either a typed, auditable delegation mechanism with restricted consent and parent notification, or an explicit unsupported-flow with fresh-approval behavior and documentation.