Codex Desktop secondary folder is not propagated to workspace_roots or writable permissions

No source files or tests are named. Start by tracing how the Desktop secondary-folder state is carried into the next task turn, comparing the injected environment_context.workspace_roots with permission_profile.file_system. Done means an attached writable folder appears in both contexts and writes no longer require repeated approval without recreating the task.

What version of the Codex App are you using?

26.721.41059 (build 5848)

What platform is your computer?

macOS 26.2, arm64

What issue are you seeing?

A folder added through the Codex Desktop UI as a secondary folder for an existing task is displayed as attached in the app, but it is not propagated to the task's effective sandbox context.

The secondary folder is absent from both:

• environment_context.filesystem.workspace_roots
• writable entries in permission_profile.file_system

The agent can inspect/read the sibling worktree, but writes fail with Operation not permitted and require out-of-sandbox approval. This produces repeated permission prompts even though the folder was already added through the app UI for that task.

Sanitized example of the injected context:

cwd: /path/project.worktrees/PRIMARY
workspace_roots:
  - /path/project.worktrees/PRIMARY
  # /path/project.worktrees/SECONDARY is missing

permission_profile:
  file_system:
    entries:
      - access: write
        path: /path/project.worktrees/PRIMARY
      # no entry for SECONDARY

A write into the secondary worktree then fails:

cp: /path/project.worktrees/SECONDARY/...: Operation not permitted

This appears to be a synchronization bug between the secondary-folder state shown by the Desktop UI and the permission/workspace state injected into an already-running task.

What steps can reproduce the bug?

1. Open an existing Codex Desktop task whose primary folder is a Git repository or worktree.
2. Create or select a sibling Git worktree outside the primary folder.
3. Add that sibling worktree to the task using the Desktop app's secondary-folder UI.
4. Confirm that the app shows the secondary folder as attached.
5. Continue the same task and ask Codex to create or copy a file inside the secondary worktree.
6. Observe an approval prompt or an Operation not permitted failure.
7. Inspect the next turn's environment_context.
8. Observe that the secondary folder is absent from workspace_roots and from the writable permission entries.

The problem persists across subsequent turns in the same task.

What is the expected behavior?

Once a secondary folder is attached to a task with write access:

• it should be included in the task's workspace_roots;
• it should receive the corresponding writable permission entry;
• ordinary writes inside it should not require repeated escalation;
• the effective permissions should update in the existing task without requiring the task to be recreated.

If secondary folders are intentionally read-only, they should still appear in the injected roots/permission context and the UI should clearly communicate that limitation.

Additional information

Related but distinct reports:

• #6542 covered secondary folders in a VS Code multi-root workspace and was closed when multi-root was not supported.
• #27943 requests multiple workspace folders in the Desktop app. In this Codex App version, the UI already exposes a secondary-folder control; this report concerns the control not updating the effective sandbox permissions.
• #33322 describes an existing task losing write permissions after a model switch. This report does not involve a model switch: only adding a secondary folder to the current task.