Skip to content

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

Open
Open
[Windows][26.825.4187.0] app update recreates config.toml with inherited ACL and drops file-level privacy#41382
Labels
appIssues related to the Codex desktop appbugSomething isn't workingconfigIssues involving config.toml, config keys, config merging, or config updateswindows-osIssues related to Codex on Windows systems

Description

@PracticalSwan
PracticalSwan
opened on Aug 28, 2026

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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    configIssues involving config.toml, config keys, config merging, or config updates
    on Aug 28, 2026

  2. PracticalSwan commented on Aug 28, 2026

    @PracticalSwan
    PracticalSwan
    on Aug 28, 2026 – with ChatGPT Codex Connector
    Author

    Additional reproduction on the same Windows build (OpenAI.Codex_26.825.4187.0_x64__2p2nqsd0c76g0, bundled codex-cli 0.150.0-alpha.12.2) shows this is not limited to the app-update path.

    I changed an existing [desktop] setting in config.toml while Codex Desktop was closed. Before launch, the file still had the intended protected DACL: inheritance disabled, one explicit current-user FullControl ACE, and no CodexSandboxUsers ACE.

    After launching Codex Desktop, the setting itself remained intact, but config.toml had been rewritten/replaced and its file-level privacy was lost again:

    • AreAccessRulesProtected = false
    • parent ACL inheritance restored
    • inherited CodexSandboxUsers read access returned

    Reapplying only the narrow file DACL after launch restored the intended privacy and Codex continued operating normally.

    So the likely affected boundary is broader than the updater: at least one ordinary Desktop config rewrite/replace path also creates the replacement file with parent inheritance instead of preserving the existing security descriptor. No configuration contents, capability values, or authentication material are included here.

  3. PracticalSwan commented on Aug 31, 2026

    @PracticalSwan
    PracticalSwan
    on Aug 31, 2026 – with ChatGPT Codex Connector
    Author

    Fresh reproduction on the newer Windows Desktop build.

    Current environment:

    • Codex Desktop: OpenAI.Codex 26.825.6671.0
    • bundled CLI: codex-cli 0.151.0-alpha.7.2
    • Windows 11 x64

    Earlier today the existing %USERPROFILE%\.codex\config.toml had a protected current-user-only DACL. A later integrity check found that Desktop had recreated the file at 2026-08-31 21:52:39 +07:00 while the Desktop process remained running.

    The replacement again has:

    • AreAccessRulesProtected = false
    • inherited current-user FullControl
    • inherited SYSTEM FullControl
    • inherited Administrators FullControl
    • inherited CodexSandboxUsers ReadAndExecute

    The parent .codex directory carries the same sandbox-group ACE, so the broadened access is again coming from replacement-file inheritance. auth.json and the local integration's separate secret files remained protected; only config.toml regressed in this check.

    No configuration contents, endpoint capability values, authentication material, or secret values are included here. This confirms the config rewrite/replace ACL regression persists on 26.825.6671.0, not only the older 26.825.4187.0 build.

  4. PracticalSwan commented on Sep 2, 2026

    @PracticalSwan
    PracticalSwan
    on Sep 2, 2026 – with ChatGPT Codex Connector
    Author

    Fresh Windows reproduction on 2026-09-02 with Codex Desktop 26.825.6671.0 / bundled CLI 0.151.0-alpha.7.2: %USERPROFILE%\.codex\config.toml again had AreAccessRulesProtected=false and inherited a broad CodexSandboxUsers/Users-family allow ACE, while auth.json and the integration's separate secret files remained protected. Reapplying a current-user-only protected DACL to config.toml restored normal operation, and a subsequent bundled codex doctor --json left the repaired DACL intact. No config contents or capability values were inspected or included. This confirms the ACL-loss behavior persists in 26.825.6671.0, beyond the original 26.825.4187.0 reproduction.

  5. PracticalSwan commented on Sep 4, 2026

    @PracticalSwan
    PracticalSwan
    on Sep 4, 2026 – with ChatGPT Codex Connector
    Author

    Fresh reproduction on the current Windows Desktop build after a full app restart:

    • OpenAI.Codex Desktop 26.901.4073.0, bundled codex-cli 0.153.1.
    • Before restart, config.toml had already been repaired to an owner-only/protected DACL.
    • I fully terminated the verified packaged Desktop process tree, relaunched OpenAI.Codex_2p2nqsd0c76g0!App, and then re-ran the same ACL check.
    • config.toml had regressed again to protected=False while auth.json, the router caller capability, and the router internal capability all remained protected.
    • Repairing only config.toml with the existing owner-only private-file helper restored protected=True.

    No config contents, identities, tokens, or capability values are included. This shows the ACL rewrite regression still reproduces on 26.901.4073.0 / 0.153.1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingconfigIssues involving config.toml, config keys, config merging, or config updateswindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions