[Windows][26.825.4187.0] app update recreates config.toml with inherited ACL and drops file-level privacy

What version of the Codex App are you using?

Codex Desktop / ChatGPT package: OpenAI.Codex_26.825.4187.0_x64__2p2nqsd0c76g0

Bundled Codex CLI relocated by the app: codex-cli 0.150.0-alpha.12.2

Platform

Windows 11 x64.

Summary

After this Codex Desktop update, %USERPROFILE%\.codex\config.toml was recreated and lost its existing protected file-level DACL. The replacement inherited the broader %USERPROFILE%\.codex directory ACL, including read access for the managed CodexSandboxUsers group.

This matters because config.toml can contain user-supplied endpoint/configuration values that are intentionally protected more tightly than the rest of CODEX_HOME. In this reproduction a local integration stores a capability-bearing loopback base URL there. No capability value or config contents are included in this report.

Evidence

Immediately before the Desktop update, an independent local integrity check reported the existing config.toml as protected with a current-user-only Windows ACL.

Immediately after the update, that same check failed. Filesystem metadata showed the replacement file was created at 2026-08-28 17:48:19 UTC; the app's newly relocated bundled codex.exe was written at 2026-08-28 17:48:24 UTC.

The post-update file ACL was:

• owner: current Windows user
• AreAccessRulesProtected = false
• inherited SYSTEM FullControl
• inherited BUILTIN\Administrators FullControl
• inherited current-user FullControl
• inherited CodexSandboxUsers ReadAndExecute

The parent %USERPROFILE%\.codex directory intentionally carries the sandbox-group read ACE, so recreating the file with default inheritance broadened access automatically.

After restoring only config.toml to a protected DACL with one explicit current-user FullControl ACE, Codex continued to load the configuration normally.

Steps to reproduce

1. On Windows, ensure %USERPROFILE%\.codex\config.toml already exists.
2. Give that file a protected DACL (AreAccessRulesProtected = true) that is narrower than the parent .codex directory ACL.
3. Update Codex Desktop to 26.825.4187.0 through the normal app update path.
4. Inspect the file metadata and ACL after the update.
5. Observe that config.toml has been recreated and now inherits the parent directory ACL, including CodexSandboxUsers read access.

Expected behavior

An app update should preserve the existing security descriptor of the user's config.toml when replacing or migrating it. If the updater must replace the file, the replacement should retain the previous DACL (or otherwise avoid broadening access) before it becomes the live config file.

The sandbox group's access to the .codex directory itself can remain unchanged; the issue is the loss of the narrower ACL on an existing file.

Actual behavior

The update recreates config.toml with inherited permissions, silently discarding the file's stricter ACL.

Impact

This can expose sensitive user-supplied configuration to principals that intentionally had no access to the pre-update file. The regression is silent unless the user or an integration explicitly audits the DACL.

Duplicate search

I searched the tracker for config.toml, CodexSandboxUsers, Windows ACL/update, and config recreation. Existing reports cover broader sandbox ACL problems, but I did not find one for the Desktop updater specifically replacing an existing config.toml and dropping its protected DACL.

Start by tracing the Windows Desktop updater's normal update path and how it recreates %USERPROFILE%.codex\config.toml when relocating the bundled codex.exe. Compare the replacement file's security descriptor with the pre-update file. Done means an existing protected DACL is retained, or access is not broadened, after the update while Codex still loads config.toml normally; reproduce the ACL steps on Windows.