Codex Desktop create_thread intermittently downgrades Full Access worktree children to managed approval mode

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

Windows package: OpenAI.Codex_26.818.5229.0_x64__2p2nqsd0c76g0

Bundled child-session runtime: 0.149.0-alpha.4.1

Workspace dependencies shown by the app: 26.819.11345

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows 11 Pro 10.0.26200, x64

What issue are you seeing?

A parent task running through Codex Desktop Voice/realtime coordination had effective Full Access:

approval_policy = never
sandbox_policy = danger-full-access
permission_profile = disabled

All visible configuration layers (User config, project config, and Admin config) also showed Never ask for approval and Full access. The global config contained:

approval_policy = "never"
sandbox_mode = "danger-full-access"

The parent then used the official create_thread tool to create a project task with:

{
  "target": {
    "type": "project",
    "environment": { "type": "worktree" }
  }
}

The call did not contain a permission override. The current create_thread tool schema does not expose one.

Nevertheless, the worktree child started its first turn with:

approval_policy = on-request
approvals_reviewer = user
sandbox_policy = managed / restricted workspace
network = restricted
permission_profile = managed

The child immediately displayed manual approval dialogs for routine operations such as git fetch and a read-only WSL command. Its task-level UI showed Approve for me, even though the parent and every default configuration layer were Full Access. The user did not select that mode.

The persisted task records confirmed the divergence:

parent: approval_mode=never, sandbox_policy.type=disabled
child:  approval_mode=on-request, sandbox_policy.type=managed

This appears intermittent rather than a deterministic default. In a sample of the 20 most recent delegated child tasks stored locally, 18 started with never/disabled and 2 started with on-request/managed.

Changing the child back to Full Access while its first turn was running updated pending app state, but the active turn retained its original managed permission snapshot until a later turn.

What steps can reproduce the bug?

1. On Codex Desktop for Windows, set User, project, and Admin defaults to Never ask for approval + Full access.
2. Start a parent task and verify its effective turn context is:

never / danger-full-access / disabled.

1. From that parent, call the official create_thread tool for a saved Git project with:

environment: { type: "worktree" }.

1. Let the child begin its automatically started first turn.
2. Inspect the child's task permission selector, first turn_context, and persisted task row.
3. Intermittently observe that the child starts as:

on-request / user / managed.

1. Ask the child to run git fetch or another operation outside its restricted writable roots.
2. Observe a manual approval dialog.

What is the expected behavior?

A child created with create_thread should inherit the effective Full Access mode from the host/defaults or the Full Access parent:

approval_policy = never
sandbox_policy = danger-full-access
permission_profile = disabled

If permission inheritance isn't intended, create_thread should expose an explicit permission profile or create the child paused so the user can choose before its first turn starts.

Permission changes made while a turn is active should either apply to subsequent tool calls or clearly state that they only apply to the next turn.

Additional information

This is related to, but distinct from:

• #25590 — permission drift when resuming an existing thread. This report occurs at new worktree-child creation.
• #25810 — broader new-thread/handoff behavior where the reported host-level state was guardian-approvals. Here the parent, host selection, and all config layers were verified Full Access at creation time.
• #33282 — create_thread failing to inherit Auto Approval. This report reproduces the same creation boundary with Full Access / never / danger-full-access.

Official configuration references:

• https://learn.chatgpt.com/docs/config-file/config-basic
• https://learn.chatgpt.com/docs/config-file/config-advanced

Thread IDs, repository names, account details, and local paths are omitted. I can provide focused redacted task records and rollout excerpts if needed.