Windows Desktop: writable Documents roots can be CFA-blocked without a safe file-operation channel

What version of the Codex App are you using?

Codex Desktop for Windows 26.715.8383.0 with bundled codex-cli 0.145.0-alpha.27.

What platform is your computer?

Windows x64 with Microsoft Defender Controlled Folder Access enabled.

What issue are you seeing?

A workspace under the Windows Documents known folder can be declared writable by the task envelope while Codex's actual file-writing process is blocked by Controlled Folder Access. The native editor returns a generic failure, and alternate shell or helper processes have independent filesystem visibility and CFA identities. Codex can therefore cycle through incompatible writers and describe the result as a user permission problem even though task authority was already granted.

In a bounded reproduction, a native editor mutation failed and authoritative readback showed no commit. A tightly correlated Defender event identified the Codex writer as CFA-blocked. A separate OpenAI-signed helper could read the same source but its copy/create operation failed with a generic file-not-found-style error while a correlated Defender event identified that distinct helper as CFA-blocked. This established that the source existed and was visible; the generic error did not communicate the real enforcing layer.

The current model-visible Desktop surface exposed no supported host-owned transactional filesystem channel that bound writer identity, operation, endpoints, commit state, and recovery. Substituting PowerShell or another broad executable is not a safe repair.

What steps can reproduce the bug?

1. Enable Defender Controlled Folder Access.
2. Open a Codex Desktop workspace below Documents and start a task that lists the workspace as writable.
3. Put a disposable file in the workspace.
4. Ask Codex to update or delete it through the native editor.
5. Reconcile the target and inspect Defender Operational events for the operation window.
6. Observe that the task-level writable grant and the actual writer's CFA capability can disagree, while the tool result does not surface that distinction.

What is the expected behavior?

Codex Desktop should provide a supported host-owned Windows file-operation channel whose process identity and CFA compatibility are part of the tool contract. It should either complete the exact operation with an authoritative commit/readback receipt, or fail closed with a structured result identifying the reached boundary, operation, commit state, and enforcing layer such as CFA_BLOCK.

For updates and recovery, the channel should support expected-state checks and atomic or interruption-safe replace/restore. If no such channel is available, Codex should mark the operation unavailable before dispatch and prevent unreceipted writer substitution. It should not direct users to broadly allowlist shells or script engines.

Additional information

Related: #30009 covers Windows apply_patch sandbox failure/hanging. This report is distinct because the observed operations reached process-specific CFA enforcement and the missing capability is an end-to-end, transaction-safe Windows writer with accurate failure classification.

Detailed receipts were retained locally. They are intentionally not attached because they contain host-specific paths and metadata; a redacted subset can be provided if maintainers request particular fields.