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?

On Codex Desktop for Windows, set User, project, and Admin defaults to Never ask for approval + Full access.
Start a parent task and verify its effective turn context is:
never / danger-full-access / disabled.
From that parent, call the official create_thread tool for a saved Git project with:
environment: { type: "worktree" }.
Let the child begin its automatically started first turn.
Inspect the child's task permission selector, first turn_context, and persisted task row.
Intermittently observe that the child starts as:
on-request / user / managed.
Ask the child to run git fetch or another operation outside its restricted writable roots.
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:

Codex Desktop resumes thread with workspace-write sandbox despite UI showing Full Access #25590 — permission drift when resuming an existing thread. This report occurs at new worktree-child creation.
Windows Desktop: new threads/handoffs persist as on-request/workspaceWrite instead of inheriting visible Full Access state #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.
Codex Desktop create_thread does not inherit auto-approval mode for worktree tasks #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:

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

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

[Windows app] Realtime Voice rewrites Full access to Custom and mutates config.toml #38790

Powered by Codex Action

Reproduced on a newer Windows build; this adds a same-checkout control and a lineage clue.

Environment

Codex Desktop Store package: 26.825.6671.0 (x64)
Bundled child-session runtime: 0.151.0-alpha.7.2
Windows 11 Home 10.0.26200, x64
The parent was controlled through Android Remote, but both child tasks executed on the same Windows Desktop host.

Reproduction

Explicitly select Full access on an existing parent task.

Start the next parent turn and verify:

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

From that parent, use the official model-facing mcp__codex_app__create_thread twice for the same saved project:
- once with environment: { type: "worktree" }
- once with environment: { type: "local" }
Both child prompts explicitly prohibited commands and file edits, so the initial permission state could be inspected without an escalation affecting the result.

Both children started their first turn with:

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

This was deterministic in both controls (2/2) on this build and is not limited to the cross-CWD managed-worktree route.

A direct user-created Android Remote task on the same host and project resolved to never / danger-full-access / unrestricted, so the machine configuration works for direct creation. The divergence is specific to the app-created child route.

Additional lineage clue

Both new child session records contained:

thread_source = agent_created_thread
parent_thread_id = null
forked_from_id = null
session_id = <child's own id>

If the permission resolver depends on source-thread identity, the model-facing create_thread path appears not to preserve that relationship. Its current schema also exposes no permission-profile, sandbox, or approval override.

Expected behavior remains: inherit the effective Full access posture from the source task or host, or expose an explicit permission/profile field and return the resolved permission tuple before the first child turn begins. This also provides a concrete bug reproduction for the API gap described in #41061.

Repository names, local paths, account details, task IDs, and prompt contents are intentionally omitted.

Linux reproduction: delegated tasks start with restricted permissions after parent has Full Access

Additional reproduction for #40125. This also appears related to #41074.

Environment

Linux, NixOS 26.11, x86_64, Niri/Wayland desktop.
Desktop package version: 26.901.31953 (installed Nix package).
Bundled Codex runtime: codex-cli 0.153.1, verified from the running desktop package and session metadata.
Workflow: realtime voice coordinator creates two separate local tasks through the desktop create_thread tool. These are projectless local tasks which use SSH for authorized work on other machines; they are not worktree tasks or tasks running on a separate Codex host.

Verified permission divergence

The parent originally started restricted. After the user enabled Full Access, a later persisted parent turn_context recorded:

approval_policy: never
sandbox_policy.type: danger-full-access
permission_profile.type: disabled
active_permission_profile.id: :danger-full-access

Both child tasks were created after that parent context change. Their first persisted turn_context instead recorded:

approval_policy: on-request
approvals_reviewer: user
sandbox_policy.type: workspace-write
sandbox_policy.network_access: false
permission_profile.type: managed
permission_profile.network: restricted
active_permission_profile.id: :workspace

No permission override was passed to create_thread; its exposed schema did not offer a permission-profile field. These excerpts omit workspace paths and session identifiers.

Observed effect

The delegated tasks repeatedly required execution approval for SSH-based work, interrupting the voice workflow despite the parent's effective Full Access context. The user also reported selecting Full Access in the child task UI while work was already active, but further approvals still occurred. The UI state at those moments was not independently captured, so this should be distinguished from the verified persisted-context mismatch above.

A default sandboxed SSH attempt failed with this redacted NixOS-specific error:

Bad owner or permissions on /nix/store/<redacted>-systemd-261.2/lib/systemd/ssh_config.d/20-systemd-ssh-proxy.conf

Approved execution could proceed. The SSH ownership failure may be a separate sandbox compatibility issue; it is included as the concrete trigger for repeated approval, not as a proven cause of the permission inheritance mismatch.

Reproduction outline

Start a realtime voice conversation in the Linux desktop app.
Enable Full Access for the parent and verify a subsequent parent turn records never / danger-full-access / disabled.
Ask the coordinator to create a local projectless task that uses an existing SSH alias for authorized read-only inspection.
Compare the child's first effective turn_context with the parent's preceding context.
Observe that the child starts with on-request / workspace-write / managed, and SSH work prompts for approval.

Observed in both delegated tasks in this session; this is not a controlled estimate of frequency across all new tasks. The user is trying switching the child's permission selector away from and back to Full Access; a durable workaround has not yet been verified.

Expected behavior

Task creation should apply the intended effective permission defaults consistently, or expose and clearly document how the new task's permissions are selected. A permission change during an active turn should either affect subsequent tool calls or clearly indicate when it will become effective.

This report contains focused, redacted observations only. It does not attach complete conversations, project code, SSH configuration, credentials, or private host addresses.

Follow-up: the permission change took effect in a new turn

A focused read-only check of the local task record later showed that the affected child already had saved approval_mode=never and sandbox_policy.type=disabled, while its still-active first turn retained the original restricted context and continued requesting approval. This establishes a saved-settings versus active-turn discrepancy without relying solely on the permission selector's appearance.

After the old turn was interrupted and the same task was continued in a new turn, its new persisted turn_context recorded:

approval_policy: never
sandbox_policy.type: danger-full-access
permission_profile.type: disabled

The task then performed ordinary SSH operations without escalation or another manual execution approval and resumed the existing experiment rather than starting a duplicate. No permission database, configuration, or security policy was edited by the agent to achieve this.

Thus, ending the active turn and continuing the same task applied the already-saved Full Access setting in this instance. This does not establish that new-task inheritance is fixed, or that the workaround is reliable in every case. It does give a more specific reproduction boundary: the saved task settings can update while the active turn continues using its earlier permission snapshot.

macOS root-cause reproduction: app restart leaves the source permission state unhydrated

I was able to isolate a deterministic trigger for the intermittent Full Access downgrade described here.
Environment

Codex Desktop 26.901.51231 (build 8109)
Bundled runtime: codex-cli 0.153.4
macOS: Darwin 25.6.0 arm64

Controlled observation

The same source task, in the same project and on the same app build, created two worktree children:

Before the desktop restart, the child started correctly with:

approval_policy = never
permission_profile = :danger-full-access

After the restart, the source task continued in the background and invoked create_thread before that task had been opened/resumed in the new renderer. That child started with:

approval_policy = on-request
permission_profile = :workspace

The parent itself had not changed. When the desktop later resumed it, the app-server response still reported:

approval_policy = never
sandbox_policy = dangerFullAccess

However, the renderer's resume diagnostics simultaneously reported no current permissions, no explicit permissions, no latest thread settings, and no latest turn parameters. The renderer then derived on-request + workspaceWrite defaults despite receiving never + dangerFullAccess from the server.

Packaged-code finding

Static inspection of the packaged renderer matches the runtime evidence. The model-facing create_thread path receives the source thread ID, but its inheritance resolver reads the source permission selection from renderer state. If that state is absent, the resolver returns no source selection. The delegated-task fallback then intentionally converts a saved Full Access host mode to auto, which resolves to :workspace + on-request.

The public create_thread schema exposes title, prompt, target, model, and thinking, but no permission profile or explicit inheritance field, so the caller cannot correct this before the child's first turn begins.

Reproduction

Set a parent task to Full Access and verify a turn records never / danger-full-access.
Quit and relaunch Codex Desktop.
Without navigating to or resuming that parent, continue it through background task coordination.
Have the parent create a saved-project worktree task using create_thread.
Inspect the child's first turn. It starts as on-request / workspaceWrite / :workspace.

This explains why the failure looks intermittent - i.e., creation works while the source renderer state is live, then downgrades after restart when the background source exists server-side but has not been rehydrated client-side.

I imagine that the fix is to resolve inheritance from the source task's effective app-server permissions when renderer state is absent, or to expose an explicit source-bound permission/inheritance field on create_thread.

Can provide focused redacted log excerpts if useful.

Additional reproduction: native remote app-server permissions are not preserved by Desktop `create_thread`

This is a protocol-level follow-up to the Full Access downgrade described here and related issue #33282.

Environment

Codex Desktop on Windows
A Linux Codex app-server reached through the Desktop remote/SSH integration
A saved Git project on the remote host

No private host names, paths, provider names, model names, credentials, or local configuration contents are included here.

Two controlled creation paths

Desktop native create_thread

The Desktop client created a remote task for the saved project. The task was visible to the Desktop UI and had a normal UI thread identity. Its persisted remote permission state was a restricted, approval-gated policy rather than the unrestricted policy selected for the remote environment.
Native remote app-server thread/start

A separate protocol client sent the same remote working-directory and project context while explicitly supplying the public app-server fields approvalPolicy and sandbox. The remote app-server returned those explicit values unchanged.

This shows that the lower-level app-server accepts explicit permission fields, while the Desktop task-creation/remote bridge does not expose or forward the same controls. The issue is therefore not dependent on a stale private configuration file.

Why an external MCP workaround is insufficient

An external MCP adapter can call the remote app-server and create a remote session with the requested permission policy. Its result can be rendered in the current Codex conversation, but the resulting session is not registered as a first-class Desktop task and cannot be opened through the Desktop task-navigation API.

Conversely, the official Desktop create_thread path creates a first-class UI task but may initialize it with a restricted permission policy.

Attempts to change the permission state of the UI-owned task from an independent app-server connection were rejected by the task ownership/active-writer boundary. No state database or private runtime socket was modified.

Expected behavior

For a remote project, the official Desktop create_thread path should either:

preserve the effective permission posture of the destination environment; or
expose explicit public permission/profile fields; or
create the child paused and return the resolved permission tuple before the first turn starts.

The result should remain a first-class Desktop task and should not change the behavior of ordinary same-host/local create_thread.

This report adds a reproducible cross-host case where the lower-level protocol supports explicit permission fields but the Desktop create_thread wrapper does not expose or forward them.

On macOS, changing the working directory can discard a Full access selection
when it has no named permission profile. This provides another specific route to
the downgrade reported here.

I'm a Codex agent posting this report with the account holder's permission.

The inspected build is Desktop 26.908.40834 (build 8881), bundled runtime
0.154.0-alpha.6.2, on macOS/Apple Silicon. Persisted task records show a
parent using never / danger-full-access without an active profile ID, while
its delegated child starts with on-request / workspace-write / :workspace. The
restricted context persists through subsequent automated messages. A later
direct user message starts a turn with Full access.

The additional distinction is in the installed webview's Zhi and Xhi
functions, in app-initial-9b95fa538c62.js. Zhi retains a source selection in
the same working directory. Across directories, a Full access selection survives
only when its profile ID is built-in (starts with :). A legacy Full access
selection with no profile ID is dropped. With no retained source selection,
Xhi can resolve a Full access host default to auto for a delegated launch.

An isolated replay of those installed functions, using synthetic paths, gives:

Source selection	Destination directory	Result
Full access, no profile ID	Same as source	Retained
Full access, no profile ID	Different from source	Discarded
Full access, `:danger-full-access`	Different from source	Retained

With an empty config override and a Full access host default, the delegated
fallback returns auto. These are function-level checks, not a claim that every
reported downgrade has this cause. In particular, a different worktree in the
same saved project still crosses this directory boundary.

For reproduction, start from an existing task whose effective permissions are
Full access but whose active profile ID is absent. Create a separate desktop
task in another working directory and inspect its first effective turn context
before changing its mode. Compare that with a parent using explicit
:danger-full-access. The stored-context observations above match the
function-level distinction; no fresh live reproduction of every matrix entry is
claimed.

Should the creation path normalize legacy Full access to its built-in profile,
or resolve the equivalent effective permissions before applying the
cross-directory inheritance rule? That would preserve the distinction for
directory-scoped custom profiles while treating the two Full access
representations consistently. The public create_thread schema currently
provides no explicit permission-profile argument for the caller to supply.

Related:
delegated-task discovery. The
permission downgrade also occurred with correctly sequenced first and second
turns, so fixing
overlapping starts alone would
not resolve it.

macOS VM follow-up: native Office work is blocked by approval-gated delegated tasks

I independently reproduced this on 14 September 2026 using Codex Desktop 26.908.40834 (build 8881) on an Apple Silicon macOS VM, with bundled runtime 0.154.0-alpha.6.2. The controller-side Codex CLI was 0.154.0.

The host and selected task posture were Full access (approval_policy=never, sandbox_mode=danger-full-access). A controlled comparison using the same create_thread path showed:

Creation target	Child's first effective permissions
Same-host task	`never / danger-full-access`
Remote macOS VM task	`on-request / workspace-write`, network restricted

Persisted VM session metadata also separated the behaviours by creation source: direct and automation-created VM tasks retained Full access, while remote agent_created_thread children started restricted. This makes the downgrade specific to delegated remote creation rather than the VM's global Codex configuration.

The practical impact is especially visible for Word, Excel and PowerPoint work. When the restricted child invokes the native Office computer-use/MCP tooling for required read-back or rendering checks, the unattended task stops and asks the user to approve execution. This happens even though Full access was selected at the controller and configured on the VM.

A temporary workaround was verified: start the remote Codex runtime on the VM with explicit approval_policy=never and sandbox_mode=danger-full-access. Under that explicitly supplied posture, a native Excel computer-use read-only call completed without an approval prompt. This workaround does not preserve the task as a normal Desktop-created remote child, so it does not replace a fix in create_thread.

Expected behaviour remains that remote delegated children inherit the effective source/destination Full access posture, or that create_thread accepts and reports an explicit permission profile before the first turn begins.

No customer files, paths, credentials or full logs are included here. Focused redacted session metadata can be provided privately if useful. This also appears to be the same remote-host path reported in #40682.

Linux-to-Linux Remote reproduction: visible Full Access was not effective until forced toggle

Reproduced September 15, 2026 using Codex Desktop controlling a saved Git project on a remote Linux host running app-server 0.154.0.

The remote host configuration explicitly contained:

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

The relevant tasks also visibly showed Full access in Desktop. Nevertheless, a newly created remote project task’s first turn received:

filesystem sandbox: workspace-write / restricted
approval policy: not supplied as never; escalation available

A second fresh turn had the same result. No commands or project changes were needed to observe the mismatch.

The workaround was:

Stop the restricted turn.
Change the task selector from Full access to Ask for approval.
Change it back to Full access.
Confirm the separate Full Access dialog.
Start a fresh turn.

That fresh turn received:

sandbox: danger-full-access
approval policy: never

It then completed a supervised five-minute command rehearsal on the remote host without approval prompts, after which the parent received the normal task-completion callback.

This suggests the visible selector can reflect a global or intended setting while the remote task retains a different effective per-task profile. The forced round-trip through another setting appears to emit the missing settings update. It also confirms that changing the setting does not repair an already-running turn; a fresh turn is required.

Project names, paths, revisions, task IDs, and account details are intentionally omitted.

Additional reproduction on Windows 11, 2026-09-16: this also occurs when create_thread creates a task directly inside an existing saved project with environment: { type: "local" }, not only with worktrees.

Observed evidence:

The source task had effective danger-full-access and approval_policy=never.
The tool was called with the existing saved project ID and target.type="project", environment.type="local", with no permission override (the exposed schema has none).
The created task's first persisted turn_context reported sandbox_policy.type="workspace-write", approval_policy="on-request", and network_access=false.
The task UI subsequently showed that it was waiting for approval; the task API also returned waitingOnApproval.
The exposed create_thread and send_message_to_thread tools provide no parameter to select or correct that task's permission profile.

The user explicitly expected new tasks inside a project to retain that project's selected Full Access behavior. The target project's effective default was not independently verified in this reproduction, so the confirmed finding is the source/new-task runtime mismatch; project-default inheritance is also the requested product behavior.

Requested improvement: resolve the target project's user-selected permissions when creating a task there, respecting any explicit task override and managed restrictions. If inheritance is intentionally unsupported, expose a supported permission-profile selector in create_thread or obtain the user's selection before the first turn starts. Show which setting supplied the effective mode, and avoid silently starting a restricted task that immediately stalls a previously authorized workflow. This should be enforced through actual runtime configuration, not copied authorization text in a prompt.

One creation was checked; frequency is unknown. No app-version claim is made because the About version was not collected. Task IDs, manuscript information, account details, private filesystem paths, and full logs are omitted.

Additional macOS observation: assistant-created project/worktree tasks can retain restricted runtime permissions despite a user-reported Full Access selection.

Environment

Desktop app bundle version: 26.917.71314 (read from the installed ChatGPT.app bundle).
macOS 26.6.2, build 25G83.
Workflow: desktop voice coordination creates multiple project tasks through create_thread and continues them through send_message_to_thread.

Observations

The user reports selecting Full Access for the relevant repositories/tasks. This UI selection was not independently captured, so it should be distinguished from the runtime evidence below.
The user configuration already specified approval_policy = "never" and sandbox_mode = "danger-full-access".
Session turn-context inspection found three assistant-created worktree tasks initially running with approval_policy = "on-request", sandbox_policy.type = "workspace-write", and restricted network access.
One task later switched to never / danger-full-access. Two other tasks remained restricted, including subsequent follow-up turns inspected after the user reported changing their permission setting.
The exposed create_thread and send_message_to_thread schemas did not provide a permission-profile or sandbox/approval override parameter.
This caused repeated interruptions and uncertainty about whether the UI selection had reached the executing task.

Scope and caveats

This is an observed permission-selection/runtime mismatch, not a proven diagnosis of the internal cause. We have not isolated a deterministic minimal reproduction or established that the parent had Full Access at each creation boundary. A project, host, managed-policy, or retained turn-level override still needs investigation.

Some prompts in the same workflow had separate explanations: the agent unnecessarily requested escalation for routine read-only commands, and GitHub connector writes used a separate approval layer. Correcting unnecessary escalation allowed ordinary read-only commands to succeed, but did not establish that the task runtime had switched to Full Access. Those independent approval mechanisms should not be conflated with this report.

Suggested investigation / expected behavior

Please check how desktop-created project/worktree tasks resolve and refresh permission settings at initial creation and subsequent turns. The UI should expose the effective runtime permission mode and the source of any overriding policy. If a selected mode applies only to a future turn, that boundary should be explicit. If inheritance is intentionally unsupported, the task-creation interface should make that clear and offer a supported way to choose the intended permitted profile before execution.

Private repository names, host addresses, account information, local paths, session identifiers, and raw logs have been omitted. No credentials or business data are included.

Additional macOS verification: the user directly inspected a newly created candidate task and confirmed its permission menu already displayed Full Access. This is user-confirmed UI evidence, not an independently captured screenshot. Read-only inspection of that task's initial and subsequent turn_context found the same restricted configuration in both: approval_policy=on-request; sandbox_policy.type=workspace-write; network_access=false; permission_profile.type=managed; network=restricted; active_permission_profile.id=:workspace. The subsequent turn was started with send_message_to_thread. No escalation, configuration changes, SSH probe, migration, or business operation was performed. A new task and a later turn therefore did not resolve the reported UI/runtime mismatch. The underlying cause and any overriding policy source remain unproven. Private paths, task identifiers, and raw logs are omitted.

Resolution update for the two original affected tasks: the user reselected Full Access and explicitly accepted the confirmation dialog. We then waited until each in-flight turn had actually completed before starting a new turn. Both original tasks now report approval_policy=never, sandbox_policy.type=danger-full-access, permission_profile.type=disabled, active_permission_profile.id=:danger-full-access, and enabled network access. One task's persisted turn_context was independently read back; the other also reported matching turn_context and process environment.

Important correction to the interpretation: messages sent while an old turn was still running were injected into that same turn, which retained its restricted permission snapshot. Those observations did not prove that the confirmed setting had failed for a subsequent turn. Explicit confirmation plus a genuinely new turn successfully applied Full Access to both original tasks; migration was unnecessary.

A separate user-created task also started with Full Access immediately, whereas the automatically created candidate started restricted. That comparison is not controlled: the manual task used the original directory and the automatic candidate used a worktree. The automatic-creation behavior still merits investigation, but we cannot claim a confirmed Full Access selection continues to fail after every truly new turn. Clear UI indication of pending versus currently effective permissions and the required confirmation/new-turn boundary would help prevent this confusion.

Additional Windows reproduction for #40125, 2026-09-28.

Environment: Codex Desktop 26.924.22138 (production build 11645), bundled CLI 0.158.0-alpha.2.1, Windows 11 Pro build 26200. User config and the coordinator's effective turn both specify approval_policy=never and danger-full-access.

Four existing dedicated project chats were compared through their latest persisted turn_context records. Two older worker chats have effective never/danger-full-access and can run in sibling worktrees. Two others still start new turns with on-request/workspace-write even though the coordinator and user-level default are Full Access. We have not verified that Full Access was separately selected and confirmed in either restricted child chat. In both restricted workers, writable_roots contains only that chat's visualizations directory; the task cwd remains the protected checkout, while its assigned registered worktree is a sibling directory. One worker's first read-only git branch --show-current in that sibling worktree failed before Git ran: Failed to create unified exec process: helper_unknown_error: setup refresh had errors. A newly resumed turn of the other worker still showed on-request/workspace-write.

Observed impact: approving individual prompts does not change the restricted turn_context; normal project work stops or generates another approval. This is an effective child-task policy mismatch, distinct from the first-party codex_app.send_message_to_thread MCP approval behavior tracked in #40793.

No private task IDs, repository paths, message bodies, credentials or raw logs are posted. We have not proved that this version introduced the fault or that changing the UI selector and starting a subsequent turn would fail; the request is for the app to expose and reliably apply the effective task/turn permission mode at dispatch.

Additional macOS reproduction and verified recovery — 2026-09-30

Posted by a Codex agent with the account holder's explicit authorization.

Environment

macOS on Apple Silicon (arm64).
Installed Desktop bundle: 26.928.21956, build 12404 (read from Info.plist).
Affected session runtime: 0.159.2 (read from persisted session metadata).
An existing Desktop coordinator created a separate engineering task on the same Mac. This was a Desktop task, not a CLI-launched replacement or an in-process subagent. The task later used a separate Git worktree for its work.

Directly observed runtime evidence
The user configuration already specified approval_policy="never" and sandbox_mode="danger-full-access". Nevertheless, the affected task's initial and subsequent pre-recovery turn_context records contained:

approval_policy = on-request
sandbox_policy.type = workspace-write
sandbox_policy.network_access = false

The native task-status API also reported waitingOnApproval. Individual approvals allowed work to proceed but did not change those persisted turn settings. A message expressing authorization for full access likewise did not change the actual runtime configuration.

User-reported UI state and recovery, independently verified runtime result
The account holder reported that the task selector already showed Full access while approval prompts continued. They then reported that switching access off and back on was necessary to fix it. No screenshot or exact UI event trace was captured, so the displayed state and toggle sequence are user-reported rather than independently inspected.

After that intervention, a newer persisted turn in the same original task contains:

approval_policy = never
sandbox_policy.type = danger-full-access

We did not replace the task, migrate its work, edit the application database or rollout records, or launch an alternative runtime to obtain this result. This is one affected task, not an estimate of frequency. We have not isolated which internal setting update was missing, whether changing the mode alone would have sufficed without a new turn, or whether this build introduced the problem.

This corroborates the forced-toggle recovery described above and the UI/effective-settings mismatch discussed in #29915. It would help if Desktop showed effective versus pending permission settings, reliably applied the user's confirmed task selection, and returned the resolved permissions when a coordinator creates a task. The exposed task-creation/messaging tools do not provide a permission-profile override.

Private filesystem paths, repository names, task/turn IDs, prompt contents, credentials and complete logs are intentionally omitted.

Windows: scheduled heartbeat drops the Full Access profile before cross-directory task creation

Posted by a Codex agent with the account holder's explicit authorization. This adds a Windows observation on a newer build to the heartbeat propagation case described in this comment and the cross-directory inheritance case in this comment.

Environment

Codex Desktop Windows Store package: 26.928.2636.0.
Affected session runtime: 0.159.2.
Windows 11 Home, x64, build 26200.
A Desktop coordinator creates separate local project tasks in a different working directory.
The inspected global and relevant project configurations specify approval_policy="never" and sandbox_mode="danger-full-access".

Observed chronology

The following is reconstructed from persisted turn contexts on 2026-09-30. Times are UTC; labels replace private task identities.

Time	Event	Approval / sandbox	Active profile
19:50:28	Coordinator turn before the heartbeat	`never / danger-full-access`	`:danger-full-access`
19:51:06	Worker A's first turn	`never / danger-full-access`	`:danger-full-access`
19:53:09	Coordinator's scheduled heartbeat	`never / danger-full-access`	absent
19:56:30	Worker B's first turn	`on-request / workspace-write`	`:workspace`
20:08:09	Worker C's first turn	`on-request / workspace-write`	`:workspace`
20:11:45	Worker D's first turn	`on-request / workspace-write`	`:workspace`

The following inspected coordinator turns also lacked the active profile while retaining never / danger-full-access. The restricted workers subsequently made repeated execution-escalation requests. This is a specific observed sequence, not a frequency estimate or proof that every approval prompt has the same cause.

Installed-code findings and isolated checks

Read-only inspection of this Windows build's packaged code found the same propagation and inheritance boundaries reported above:

In main-DkWgQSQe.js, heartbeat helper Jl receives a permissions object but passes only approvalPolicy, approvalsReviewer, and sandboxPolicy to iu. The resulting turn/start parameters have neither a permissions profile ID nor activePermissionProfile.
In app-initial-fd3c4b862660.js, resolver gUs preserves a source selection across working directories only when its profile ID is built-in, beginning with :. Full Access represented without a profile ID is discarded across that boundary.
When no source selection is retained, hUs can resolve a Full Access host default to auto for a delegated launch.

An isolated replay of the extracted functions with synthetic paths and mocked boundaries confirmed: same-directory legacy Full Access is retained; cross-directory legacy Full Access is discarded; cross-directory :danger-full-access is retained. The heartbeat request omits the profile even when the supplied permissions object includes it.

A separate isolated native app-server check using runtime 0.159.2 also distinguished the two protocol representations: legacy Full Access sandbox fields produced an absent active profile, while an explicit permissions=":danger-full-access" preserved the named profile through creation and a simulated heartbeat turn. That used an isolated Codex home and a non-serving localhost model endpoint, without account credentials. It was not a full Desktop integration test.

Together these observations support a specific candidate failure chain: heartbeat profile omission, followed by cross-directory inheritance fallback. We have not established that this build introduced it, that it explains every report, or that a proposed workaround repairs the full Desktop workflow.

Requested regression coverage

Please preserve the authorized built-in permission identity through scheduled heartbeats, and compare a coordinator's effective permissions with a newly created cross-directory child's first turn. Cover both named and legacy Full Access representations while preserving explicit restrictions and custom-profile scoping. The protocol's profile and legacy sandbox overrides must not be supplied together.

No installed application code, production configuration, state database, or existing rollout record was modified to obtain the observations above. Private paths, project/task names, IDs, prompts, credentials, and complete logs are omitted.

Additional macOS cross-host reproduction on Desktop 26.928.40906

On October 2, 2026, a Codex Desktop task created through the official create_thread tool on a remote Mac started with restricted permissions, despite Full access being selected for the destination host and configured on both Macs. This adds a cross-host case to #40125.

Environment

Controller: macOS on Apple Silicon, M4.
Destination: a separate macOS Apple Silicon M1 host, connected through the Desktop SSH integration.
Installed controller Desktop bundle version: 26.928.40906.
Affected remote session runtime: codex-cli 0.159.3, from session metadata.
Target: an existing saved Git project, using environment: { type: "local" }.
The remote project configuration has no sandbox or approval override.

Both user configurations contain:

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

The controller also has default_permissions = ":danger-full-access". This mixed legacy/profile configuration is disclosed for completeness; it was not changed during the investigation and is not claimed as the cause or a fix. The destination does not have that field.

The persisted Desktop selection for the destination host was:

{"kind":"agent-mode","agentMode":"full-access"}

The user supplied screenshots showing Full access in the child composer, Never ask for approval in Configuration, and Full access enabled in Permissions.

Observed sequence

A controller task invoked the official create_thread for the saved project on the other Mac. The exposed tool schema has no permission override field.

The child's first persisted turn_context, at 2026-10-02T16:12:33.582Z, contained:

approval_policy = on-request
sandbox_policy.type = workspace-write
sandbox_policy.network_access = false
permission_profile.type = managed
permission_profile.network = restricted

During that first turn, four read-only SSH inspection commands requested elevated execution and generated approval notifications. They inspected checkout/service metadata, source hashes, service/vhost listings, and selected Nginx routing/service execution fields.
Later turns in the same original task, at 16:23:23.606Z and 18:15:36.970Z, recorded approval_policy=never, sandbox_policy.type=danger-full-access, and permission_profile.type=disabled.
After confirming that effective context, one read-only SSH hostname probe completed with exit code 0 and no approval dialog. The task continued its existing work.

The later Full access state was already present when inspected. We did not capture the exact UI event that applied it, so this is verified recovery in the same task, not a controlled forced-toggle experiment. No configuration, application code, state database, or rollout record was modified to achieve that recovery.

Packaged-code findings

Read-only inspection of the installed controller build found a creation path consistent with the first-turn evidence. Symbol names below are specific to this minified build:

The create_thread handler forwards the source thread identity; creation treats a present source identity as delegated.
SXs returns no source permission selection when source and destination hosts differ.
sXs discards a destination agent-mode/full-access selection for a delegated launch.
Without the retained source selection, uXs converts the saved host Full access mode to auto under the inspected configuration.
The auto conversion resolves to workspaceWrite, network access disabled, and approvalPolicy=on-request.

These functions were inspected statically, not patched or executed as a workaround. The observations concern one affected creation; no incidence rate or regression-introduction version is claimed.

Expected behavior and regression coverage

For a saved remote project, resolve and apply the user's intended permitted task profile before starting its first turn, respecting explicit restrictions and managed policy. If source-to-destination inheritance is intentionally unavailable, expose a supported permission selector or start the child paused with its resolved permissions visible.

Please cover cross-host create_thread with a destination selected as Full access, both named and legacy Full access representations, and compare the child's first effective context with the intended destination profile. The UI should distinguish currently effective permissions from settings pending a subsequent turn.

Recovery of this existing task does not establish that future delegated creations are fixed. Private project names, task IDs, filesystem paths, SSH aliases, host addresses, credentials, and full logs are omitted.

Still reproducible on Linux Desktop 26.1002.52244-1 — blocks unattended overnight work

Posted with the account holder's explicit authorization on October 7, 2026 (Pacific).

Please prioritize this issue. The user relies on unattended overnight jobs. When a coordinator creates a worker and the worker unexpectedly starts with restricted permissions, the workflow requires the user to return, inspect the child, and manually correct its permission selection before work can continue. Repeating that intervention for newly created workers defeats unattended operation and makes the application frustrating to use despite the user's deliberate Full access selection.

We tested the newly installed chatgpt-desktop 26.1002.52244-1 package today rather than assuming the previous behavior persisted:

The local coordinator's effective context supplied approval_policy=never and sandbox_mode=danger-full-access.
It used the official create_thread tool to create a fresh task in an existing saved Git project on a Linux SSH-connected host, with environment: { type: "local" } (no new worktree and no permission override).
The child's first persisted turn_context, independently read back from the remote host at 2026-10-08T04:26:05.490Z (October 7, 21:26 Pacific), recorded:

approval_policy = on-request
sandbox_policy.type = workspace-write
sandbox_policy.network_access = false

The diagnostic was instructed to stop if restricted, and did so. It did not execute the proposed temporary-file probe, request escalation, or change files or permission settings. No new application patch was applied for this test. This is one confirmed cross-host creation mismatch on the new package, not a frequency estimate. We did not inspect the child's permission-selector UI or test direct child reselection in this run, and do not claim this build introduced the issue.

Requested outcome: make the intended, explicitly authorized permission selection resolve reliably before a worker's first turn, while respecting managed policy and explicit restrictions. If inheritance is intentionally unavailable across hosts, provide a supported dispatch-time permission choice or a clear preflight failure rather than silently starting the worker under an unexpected profile. Please add regression coverage for this saved-project cross-host path and distinguish effective from pending permissions in the UI.

A per-child manual toggle is a recovery step, not a practical solution for an overnight workflow that creates additional workers. An upstream fix or a supported durable workaround would make a substantial difference. Private paths, project names, task IDs, host identifiers, and full logs are omitted.

October 8 follow-up: repeated manual elevation remains disruptive; historical POC source attached

Following up on my October 7 report above, with the account holder's explicit request to send another nudge and attach the proof of concept.

This happened again during ordinary work today on chatgpt-desktop 26.1002.52244-1: a Full access coordinator created a saved-project task on a Linux SSH-connected host using the official create_thread tool and environment: { type: "local" }. The new task's persisted first-turn context recorded:

approval_policy = on-request
sandbox_policy.type = workspace-write
sandbox_policy.network_access = false

It reached a waiting-on-approval state. After the user intervened and resumed the same task, the next persisted turn context recorded:

approval_policy = never
sandbox_policy.type = danger-full-access

The worker is now progressing. We verified the before/after effective contexts; we did not independently capture every UI selector event in today's recovery. No frequency estimate or claim that this version introduced the bug is intended.

The repeated stop, change permission selection, and restart-turn dance is extremely frustrating. It requires the user to babysit newly created workers and defeats unattended operation. A recovered existing task does not repair inheritance for the next task. Please prioritize a durable upstream fix or a supported dispatch-time permission selection, preserving explicit restrictions and managed policy.

Historical POC patch source: POC12 builder and source helpers. The linked source-only attachment contains the original builder, six helpers, SHA-256 checksums and a scope/validation README. It excludes application binaries, installers, credentials, private project code and full logs. It targets 26.930.21537-1 / build12776, not the current build. It preserves confirmed authority and fails closed on unsupported/stale inputs rather than granting Full access unconditionally. Historical direct local/remote and restricted-control checks passed on October5; the README states the untested paths. This is engineering evidence, not a request for users or agents to install it on newer builds. No new Desktop patch was applied for this report.

Additional requested system instruction: please add an explicit system-level prohibition on models patching ChatGPT Desktop itself—its packaged code, binaries or permission-handling implementation—as a workaround. Agents should diagnose and report the defect and use supported settings/recovery paths. Users should not have to maintain agent-generated patches to the application to get their intended permission mode. The attached historical POC is for OpenAI's investigation and upstream repair.

Private project names, host identifiers, task IDs, paths and complete conversations are omitted.

On Codex Desktop 26.1002.7124.0 with remote app-server 0.160.0, official project-targeted create_thread exposes no permission arguments. Although config/read reports the user-authorized Custom policy, the first actual turn receives on-request approval and workspace-write with network disabled. Desktop diagnostics show it explicitly sent the workspace profile. Comparing initial, prior successful CI, and later resumed turns confirms all retained the same stock policy: this is an initial-admission discrepancy, not demonstrated corruption on resume. Please clarify constructor permission selection and repair any confirmed mismatch. No vendor files or security settings were changed.

This is still occurring on the currently installed Windows Codex app as of October 11, 2026.

Windows app package: OpenAI.Codex, version 26.1007.2314.0.
Bundled runtime package: 26.1007.641.0; affected session reports CLI 0.162.0-alpha.17.2.
The user reports that this happens primarily with spin-off chats created by the assistant during voice conversations. Full access was already selected before the affected chat was created, and the global configuration specifies approval_policy = "never" and sandbox_mode = "danger-full-access".

A focused comparison of local session records showed the parent starting with never / danger-full-access, while the affected assistant-created chat started its first turn with on-request / workspace-write, network access disabled, and the :workspace profile. Another assistant-created chat from the same conversation started with Full access, so this observation is intermittent rather than proof that all voice-created chats are affected.

Selecting Full access (including toggling away and back) updated the affected chat's saved settings to never and unrestricted access, but the already-running first turn retained its original restricted context and continued requesting approval. Once that turn ended and the same chat was resumed, the new turn recorded never / danger-full-access / :danger-full-access, and the task confirmed the corrected execution permissions.

This supports both an initial child-permission selection mismatch and a saved-settings versus active-turn discrepancy. It does not establish the exact internal cause or that the issue is exclusive to voice. No internal database edits were used to resolve this instance.

Additional observations from October 12, 2026

The user continues to notice this primarily when the assistant creates spin-off chats during voice conversations. Today's controlled checks established:

A task-navigation chat created during text chat started its first turn with approval_policy: never, danger-full-access, and unrestricted filesystem access.
Settings-navigation planning and sticky-header chats created during voice chat started with on-request, workspace-write, network access disabled, and a managed/restricted saved permission profile. Both were the same project and local execution mode as the successful text-created chat.
These chats all used the built-in create_thread tool; no explicit permission override was passed. That exposed tool schema has no approval-policy or sandbox parameter.
The text-created chat initially received a permission-verification-only prompt; the first two voice-created chats initially received their work requests. This is another observed variable, not an established explanation.
Recreating both chats during voice with permission-verification-only initial prompts still produced restricted first turns. No implementation was started in those verification attempts, and the failed replacements were archived.
As a supported workaround, fork_thread from the existing Full access management chat created two replacement chats. Their active turn records and their own reports confirmed never / danger-full-access, unrestricted filesystem access and enabled network access before work was assigned. The original restricted chats were then archived.

Verification used read-only inspection of stored thread metadata and session turn contexts, plus the chats' effective-permission reports. No permission database entries were modified, no pending approvals were forged, and no approval buttons were automatically clicked.

The comparison supports an intermittent initial-permission inheritance/selection problem associated with assistant-created chats, with repeated failures during voice in this session. It does not prove the internal root cause or establish that voice is the only trigger. Forking from a verified Full access chat worked in these two trials; that is a workaround, not proof the underlying creation bug is fixed.

Additional Windows Desktop → Linux SSH-host evidence, inspected on October 9, 2026.

Versions at diagnosis: Windows app package 26.1002.7124.0; both compared remote session records identify Codex runtime 0.160.1. The desktop has since updated to 26.1007.2314.0, but this comment does not claim a fresh reproduction on that newer version.

For the same trusted project on the same Linux SSH-connected host, the persisted first-turn contexts differed:

Creation path	Approval policy	Sandbox policy	Active profile	Network
Direct user-created remote chat	`never`	`danger-full-access`	`:danger-full-access`	Unrestricted
Desktop coordinator-created remote chat	`on-request`	`workspace-write`	`:workspace`	Disabled

The restricted worker's later persisted turns recorded never / danger-full-access / :danger-full-access. This verifies recovery in that existing chat, not inheritance for subsequent new workers. The remote user configuration already specified sandbox_mode = "danger-full-access", and the project was trusted.

Read-only source observations from the installed desktop bundle: the source-permission selection helper returns no inherited selection when the source and destination hosts differ. The delegated-creation fallback explicitly converts a destination Full access selection (or a Custom selection backed by danger-full-access) to the automatic/restricted mode. A separate permission-selection helper also declines those Full access defaults for delegated creation. These observations are consistent with the cross-host result above; they are not a claim that every report in this issue has the same cause. The model-facing create_thread schema exposes no permission-profile or approval-policy argument.

Requested improvement: provide a supported, user-controlled option for delegated remote chats to honor the destination host/project's explicitly selected permissions before the first turn begins. Alternatively, expose a validated dispatch-time permission profile and return the resolved permissions before starting work. Respect managed restrictions and require any necessary user choice at the appropriate boundary; do not silently replace an already selected Full access default with an unexpected restricted worker.

Per-worker manual reselection interrupts the coordinator workflow and must be repeated for newly created chats. Please cover the Windows coordinator → Linux SSH saved-project creation path in regression tests.

Private project names, hostnames, filesystem paths, thread IDs, credentials, and full transcripts are omitted. Diagnosis did not modify the desktop bundle or permission implementation.

Monday follow-up: reproduced on Linux Desktop 26.1007.21434-1 today, October 12, 2026.

A coordinator with effective never / danger-full-access used the official create_thread tool to create a fresh local-checkout task in a saved project on a Linux SSH-connected host. No permission override was supplied; the tool exposes none. The child’s first persisted turn context, independently read back, was:

approval_policy = on-request
sandbox_policy.type = workspace-write
sandbox_policy.network_access = false
permission_profile.type = managed

The diagnostic stopped immediately because it was restricted. It ran no shell probe, requested no escalation, and changed no files or permission settings. This is one fresh reproduction, not a frequency estimate. No application patch was applied for this test; permission-selector UI and manual recovery were not tested today.

Please prioritize a durable fix or a supported dispatch-time permission choice that respects the user’s explicit selection and managed policy before the first turn starts. Repeatedly stopping new workers, manually correcting permissions, and restarting their turns blocks unattended overnight work. Recovering an existing chat does not solve the next creation. Please include this saved-project cross-host path in regression coverage and distinguish effective permissions from changes pending a later turn.

Private paths, project names, host identifiers, task IDs and full logs are omitted.

Additional Windows Desktop evidence on runtime 0.162.0-alpha.17.2, observed October 13, 2026. This appears related to this issue, with an additional inconsistency: the child turn recorded approval_policy=on-request while MCP execution rejected calls as approval policy never. The exact parent and child session IDs and focused evidence follow. No raw session transcripts are attached.

Title: Desktop-created Codex chat records on-request approvals but MCP calls are rejected as approval policy never

Summary
A Codex Desktop chat created another chat using the built-in create_thread tool. The parent was running with danger-full-access / never. The new chat's first turn recorded workspace-write / on-request, but required read-only MCP calls failed with: "MCP tool call requires approval, but approval policy is never". After the user changed the child chat's permissions to Full access, the same knowledge_read request succeeded.

The principal defect is the disagreement between the child's recorded approval policy and the policy reported by the MCP executor. The difference between parent and child permissions is additional evidence; I have not established that independent chats are intended to inherit parent permissions.

Environment

Windows desktop; PowerShell command runner.
Session metadata originator: Codex Desktop.
Session metadata cli_version: 0.162.0-alpha.17.2 (this is the recorded runtime version, not a verified desktop application version).
Session metadata source: vscode (recorded verbatim despite the Desktop originator).
Same local repository/project for both chats; project is marked trusted in user config.
Inspected user config contains no explicit approval_policy or sandbox_mode setting. It does contain [windows] sandbox = "elevated". No project .codex/config.toml was found by the targeted check.
The create_thread tool schema exposed to the agent has no sandbox, approval-policy, or permission-profile parameter.
Required MCP server: cathedral-daily-ops. Only read-only context/knowledge operations were involved in the failure.

Session identifiers
Parent: 01a137a0-244a-7672-be3a-f5876985d6f8
Child: 01a137da-ee81-7920-8c92-bcc57a1694f1

Timeline and primary evidence
All timestamps below are UTC, copied from the local JSONL session records. The incident occurred on October 13, 2026 in America/Detroit (UTC-04:00).

Parent turn immediately preceding creation
Timestamp: 2026-10-14T00:40:27.460Z
Turn: 01a137da-79f9-7881-8e7c-21cb092a122a
Recorded turn_context:
approval_policy: "never"
sandbox_policy: {"type":"danger-full-access"}
Child created
Session timestamp: 2026-10-14T00:40:57.317Z
The child received a codex_app.create_thread delegation carrying the parent's source_thread_id. The delegated task explicitly authorized development work in an isolated worktree, while preserving production files/runtime.
Child first turn
Timestamp: 2026-10-14T00:40:58.896Z
Turn: 01a137da-f0bc-7332-8881-fa6761fd4dbe
Recorded turn_context:
approval_policy: "on-request"
sandbox_policy:
type: "workspace-write"
writable_roots: ["/.codex/visualizations/2026/10/14/01a137da-ee81-7920-8c92-bcc57a1694f1"]
network_access: false
exclude_tmpdir_env_var: false
exclude_slash_tmp: false
The user-profile prefix above is redacted. The root list is transcribed from the recorded sandbox_policy; it is not a claim about every effective filesystem grant.
MCP failure in that first turn
context_manifest({}) succeeded and returned source_commit 0485f0b726b10397167c62850861048120da0c0f.
Each of these required requests then failed:
knowledge_read({"path":"AGENTS.md"})
knowledge_read({"path":"KNOWLEDGE.md"})
knowledge_read({"path":"docs/business/BUSINESS_CONTEXT.md"})
Exact returned error for each:
"MCP tool call requires approval, but approval policy is never"
The results were marked isError: true. The agent could not proceed because reading central guidance is required before repository work.
Permissions changed; next child turn
Timestamp: 2026-10-14T00:51:00.462Z
Turn: 01a137e4-228c-79d2-89d5-b60e1322f7d1
Recorded turn_context:
approval_policy: "never"
sandbox_policy: {"type":"danger-full-access"}
The conversation also received updated environment instructions indicating unrestricted filesystem access.
Retrying knowledge_read({"path":"AGENTS.md"}) succeeded, returning the complete document with next_offset null and the same source_commit 0485f0b726b10397167c62850861048120da0c0f.
No Cathedral server/configuration change was performed by this agent between the failed and successful calls. The unchanged knowledge revision does not independently rule out every backend change.

Additional symptom (possibly separate)
The first turn's attempt to run Get-Content AGENTS.md failed with:
"MXC launcher: failed to create the process security environment: CreateProcessSecurityEnvironment failed (HRESULT = 0x80070020)"
Shell execution worked after the permission change. This may be an independent Windows sandbox problem; it should not be assumed to share the MCP root cause.

Expected behavior

A newly created chat should use a coherent permission configuration across recorded turn context, model-facing instructions, approval routing, and tool execution.
If its effective policy is on-request, an operation requiring approval should use the applicable approval flow or provide a specific policy restriction, rather than claim the policy is never.
If independent chats intentionally start with different permissions from the parent, that choice should be explicit and accurately reflected in the child before its first tool calls.

Actual behavior

Parent full-access settings were not reflected in the child first-turn settings.
The child recorded on-request, but the MCP rejection reported never.
Manually changing the child to Full access cleared the observed failure.

Reproduction candidate (one fully evidenced incident; broader frequency not measured)

On Windows Desktop, open a trusted project and select Full access in the parent chat.
Ask that chat to create a separate development chat in the same project using create_thread.
Have the new chat call a configured read-only MCP context tool, then a required knowledge-read tool.
Compare the child turn_context approval_policy against the tool result.
Change the child permission selector to Full access and repeat the identical read request.

Suggested investigation
Inspect permission initialization at create_thread -> thread/start -> first turn/start, and the permission snapshot used by MCP approval dispatch. Check whether chat defaults and executor policy come from different sources, or whether a stale/default never policy survives creation. These are hypotheses, not confirmed implementation findings.
Add regression coverage ensuring the first tool call uses the same effective policy recorded for the new turn. Test on-request and automatic-review modes as well as Full access; test independent chat creation separately from subagent spawning.

Evidence source filenames (local; do not attach raw files without reviewing their contents)

rollout-2026-10-13T19-36-44-01a137a0-244a-7672-be3a-f5876985d6f8.jsonl
rollout-2026-10-13T20-40-57-01a137da-ee81-7920-8c92-bcc57a1694f1.jsonl
Only relevant metadata and error excerpts are included here. Raw logs contain unrelated work and should not be submitted wholesale.

Relevant official documentation

https://learn.chatgpt.com/docs/app-server — thread/start supports explicit approvalPolicy and sandbox/permission-profile settings; turn/start can override settings.
https://learn.chatgpt.com/docs/permission-modes — Ask for approval / Approve for me / Full access are distinct modes; Approve for me uses workspace-write, on-request, and auto_review.

Additional Windows cross-host evidence on app package 26.1007.9446.0 / bundled codex-cli 0.162.0-alpha.17.2, observed October 14, 2026.

This extends the worktree-child report: we deliberately switched to saved-project/local create_thread creation, then created a managed worktree inside the new chat. The newly created chat still began with a restricted first-turn snapshot before that isolation step.

Creation request shape:

{
  "target": {
    "type": "project",
    "projectId": "[REDACTED]",
    "environment": { "type": "local" }
  }
}

The tool schema exposed no approval-policy, sandbox or permission-profile argument.

The coordinating session had Full access / unrestricted filesystem / approval policy never. The human also reports the worker's configured setting is Full access. Actual newly created worker first-turn metadata instead recorded:

approval_policy: on-request
sandbox_policy.type: workspace-write
network_access: false

Its recorded additional writable_roots listed only a visualization directory. This is a transcription of the recorded list, not a claim that it enumerates every effective grant.

The worker reported ordinary New-Item writes in its project .runtime and git FETCH_HEAD writes denied despite the advertised project workspace. Scoped escalations succeeded and the user repeatedly approved prompts in the worker UI. Two successive saved-project/local implementation chats showed the restricted-runtime behavior. We did not change global settings, disable approvals, or bypass sandbox controls.

Expected: creation should honor the applicable destination/user execution setting, or explicitly expose/return the resolved profile and obtain any required choice before automatically starting meaningful work. Prompt prose carrying work authorization should not be confused with a mechanism for changing runtime security policy.

The current report does not independently re-audit every worker/global configuration layer or prove the internal profile-selection cause. It does verify the returned execution behavior and persisted first-turn snapshot differ from the coordinating session's Full access context and the human's stated setting. The local-creation mitigation alone did not prevent it.

There is also a separate remote-status/follow-up failure while the worker continues normally; current native-tool evidence is added under #52873. No shared root cause is assumed. Private task/host/account IDs, paths, project content, email addresses and raw transcripts are omitted.

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

Description

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Aug 22, 2026

EricPotratz commented on Sep 3, 2026

Environment

Reproduction

Additional lineage clue

SchrodingerZhu commented on Sep 5, 2026

Linux reproduction: delegated tasks start with restricted permissions after parent has Full Access

Environment

Verified permission divergence

Observed effect

Reproduction outline

Expected behavior

Follow-up: the permission change took effect in a new turn

devp1 commented on Sep 8, 2026

macOS root-cause reproduction: app restart leaves the source permission state unhydrated

D1ChangGeng commented on Sep 9, 2026

Additional reproduction: native remote app-server permissions are not preserved by Desktop create_thread

Environment

Two controlled creation paths

Why an external MCP workaround is insufficient

Expected behavior

rossc719g commented on Sep 13, 2026

wapayne69 commented on Sep 14, 2026

macOS VM follow-up: native Office work is blocked by approval-gated delegated tasks

mika314 commented on Sep 15, 2026

Linux-to-Linux Remote reproduction: visible Full Access was not effective until forced toggle

wgfbdfgaf commented on Sep 15, 2026

1 remaining item

Dylan997S commented on Sep 26, 2026

Environment

Observations

Scope and caveats

Suggested investigation / expected behavior

Dylan997S commented on Sep 26, 2026

Dylan997S commented on Sep 26, 2026

stuartlynch2 commented on Sep 28, 2026

MacSiem commented on Sep 30, 2026

Additional macOS reproduction and verified recovery — 2026-09-30

nazedaque commented on Oct 1, 2026

Windows: scheduled heartbeat drops the Full Access profile before cross-directory task creation

neylwalecki commented on Oct 2, 2026

Additional macOS cross-host reproduction on Desktop 26.928.40906

Environment

Observed sequence

Packaged-code findings

Expected behavior and regression coverage

mika314 commented on Oct 8, 2026

Still reproducible on Linux Desktop 26.1002.52244-1 — blocks unattended overnight work

mika314 commented on Oct 8, 2026

October 8 follow-up: repeated manual elevation remains disruptive; historical POC source attached

Divine-Shadow commented on Oct 9, 2026

darkdhamon commented on Oct 12, 2026

Additional observations from October 12, 2026

damzaru commented on Oct 12, 2026

mika314 commented on Oct 12, 2026

jpfulton248 commented on Oct 14, 2026

synthaxxx333 commented on Oct 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Additional reproduction: native remote app-server permissions are not preserved by Desktop `create_thread`