Codex Desktop model switch downgrades project task to read-only, prompting for every workspace write

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

26.707.9981.0

What subscription do you have?

Education

What platform is your computer?

Windows 11 x64

What issue are you seeing?

Switching an existing Codex Desktop project task from GPT-5.4 to GPT-5.6 Sol downgraded the task's sandbox from workspace-write to read-only, even though the task retained the same project working directory and workspace root.

After the switch, ordinary source-file modifications also displayed permission prompts asking whether files in the active project could be written or modified. Normal build and render commands that needed to create output inside the project likewise requested out-of-sandbox approval.

The session history contains a direct before/after policy comparison.

Before the model switch, turns in the same task recorded:

cwd: <project>
approval_policy: on-request
sandbox_policy:
  type: workspace-write
  writable_roots:
    - <project>
model: gpt-5.4

Immediately after switching the existing task to GPT-5.6 Sol on 2026-07-15, the next turn recorded:

cwd: <project>
workspace_roots:
  - <project>
approval_policy: on-request
sandbox_policy:
  type: read-only
permission_profile:
  type: managed
  file_system:
    type: restricted
    entries:
      - path: :root
        access: read
model: gpt-5.6-sol
multi_agent_version: v1

The project root remained present in workspace_roots, but it disappeared from writable permissions.

As a result, commands following this general pattern requested elevation despite reading and writing only within the active project:

<build-tool> <project-source> --output <project-output>
<render-tool> <project-output> <project-render-directory>

The rollout history records successful patch_apply_end events after the approvals, but the task summary exposes only the eventual completed file change and does not retain the preceding UI approval interaction. From the user's perspective, Codex repeatedly asked whether it could write or modify files in the task's own working directory.

This made the task unusually approval-heavy for all kinds of normal workspace mutations, including source edits and generated build or render outputs.

This is not the existing Windows .git protection behavior and not a split-writable-root apply_patch failure. The task's injected sandbox policy itself changed to read-only at the model switch.

What steps can reproduce the bug?

1. Open an existing Codex Desktop project task on Windows whose turn context uses sandbox_policy.type = workspace-write and lists the project as a writable root.
2. Continue the same task after changing its model from GPT-5.4 to GPT-5.6 Sol.
3. Confirm that the task keeps the same cwd and workspace_roots.
4. Ask Codex to create or modify an ordinary source file below the project root and observe a write/modify approval prompt.
5. Ask Codex to run a normal build that writes an output file below the project root, for example:

``text
<build-tool> <project-source> --output <project-output>
``

1. Observe that Codex also requests out-of-sandbox approval for the project-local build output.
2. Inspect the resumed turn context and observe that the sandbox is now read-only and the managed permission profile grants only root read access.

The affected task also used one research sub-agent, but ordinary root-task build commands were already affected, so the failure is not limited to a sub-agent process.

What is the expected behavior?

Changing the model in an existing project task should preserve the task's project permissions and effective sandbox mode.

If the task was using workspace-write with its working directory as a writable root, switching to GPT-5.6 Sol should not silently replace that profile with read-only. Ordinary source edits and build, test, and render commands should be able to write below the active project root without requesting approval for every operation.

The task UI should also expose the effective sandbox mode if a model switch or task migration can change it.

Additional information

Related but distinct open reports:

• #30712 covers apply_patch failing when the Windows sandbox cannot enforce split writable roots.
• #18918 covers explicit Windows DENY ACLs on .git metadata.
• #32880 covers a newer linked-worktree .git write regression.

None of those reports describes an existing project task changing from workspace-write to read-only when its model is switched.