Codex Desktop create_thread does not inherit auto-approval mode for worktree tasks #33282

What version of the Codex App are you using (From “About Codex” dialog)?

ChatGPT Desktop powered by Codex & OWL, version 26.707.71524.

Bundled Codex CLI/runtime reported by the child sessions: 0.144.2.

What subscription do you have?

Not relevant to the local permission inheritance behavior / not checked.

What platform is your computer?

Microsoft Windows NT 10.0.19045.0, AMD64.

What issue are you seeing?

Codex Desktop's official create_thread tool does not inherit the configured auto-approval mode when it creates a task in a managed worktree.

The Desktop host default is auto approval:

agent-mode-by-host-id.local = guardian-approvals
preferred-non-full-access-agent-mode-by-host-id.local = guardian-approvals

The parent task also had:

approval_policy = on-request
approvals_reviewer = auto_review
sandbox_policy = workspace-write

However, two independently created managed-worktree child tasks both started their first turn with:

approval_policy = on-request
approvals_reviewer = user
sandbox_policy = workspace-write

As a result, the children displayed manual approval dialogs for routine escalated operations that normally pass through the auto reviewer, including git fetch, git add, and GitHub CLI commands.

This is not a GitHub CLI installation or authentication issue. The commands work after manual approval, and the same host/default configuration uses auto review in the parent task.

Changing the child task to auto approval while its first turn is already running emits a later settings update, but the active turn continues using the original user reviewer snapshot. Every later escalation in that long-running turn still asks the user manually. The new setting only takes effect on a subsequent turn.

What steps can reproduce the bug?

1. On Codex Desktop for Windows, select Auto approval as the default permission mode.
2. Start a parent task and verify its turn context contains:
   approvals_reviewer = auto_review.
3. From that task, use the official create_thread tool with:
   • a saved local project;
   • environment: { type: "worktree" }.
4. Let the child task begin its automatically started first turn.
5. Inspect the child turn context.
6. Observe that it contains:
   approvals_reviewer = user.
7. Have the child run a command that requires a normal scoped escalation, such as git fetch or git add in the managed worktree.
8. Observe a manual approval dialog instead of automatic review.

This reproduced twice in separate child tasks:

• Parent was auto_review immediately before the first create_thread call; the child started approximately one minute later as user.
• Parent was again auto_review immediately before the second create_thread call; the child started seconds later as user.

Thread IDs, repository names, account names, and local paths are intentionally omitted.

What is the expected behavior?

A child task created through create_thread should inherit the effective approval reviewer from the Desktop host default or from its parent task.

With Auto approval selected, the child should start with:

approval_policy = on-request
approvals_reviewer = auto_review

If permission inheritance is intentionally unsupported, create_thread should expose an approval/permission parameter, or create the child in a paused state so the user can select its permission mode before the initial turn starts.

Changing a task's permission mode should also either affect subsequent tool calls in the active turn or clearly indicate that it will only apply to the next turn.

Additional information

Current workaround:

1. Immediately stop the child task's first turn.
2. Select Auto approval again inside the child task.
3. Send a new “continue” message.
4. The new turn then uses auto_review.

A related Windows report, #32880, covers linked-worktree Git metadata writes and sandbox ACLs. This report is different: the commands here are deliberately escalated and succeed after approval; the defect is that the child task starts with approvals_reviewer=user despite both the host default and parent task being configured for auto review.