[App][macOS] Full Access compiles contradictory root write + deny rules; AGENTS.md startup fails with EPERM

What version of the Codex App are you using?

ChatGPT desktop app 26.903.61454 (build 8378), bundled codex-cli 0.153.4.

What subscription do you have?

Paid personal ChatGPT workspace.

What platform is your computer?

macOS 26.6.2 (build 25G83), Apple Silicon.

What issue are you seeing?

Selecting Full Access in the desktop app can produce an effective managed filesystem profile containing contradictory rules for the same workspace root: first write, then deny. The deny wins, so thread startup fails while trying to read a normal, readable project AGENTS.md:

failed to load AGENTS.md instructions for environment `local`: Operation not permitted (os error 1)

This is not a macOS file-permission problem. The file exists, is mode 0644, is readable outside the failed task, and the repository is trusted. The task rollout records the UI-selected profile as :danger-full-access, but the compiled environment profile is managed/restricted and contains both of these entries for the same special root:

{"path":{"type":"special","value":{"kind":"root"}},"access":"write"}
{"path":{"type":"special","value":{"kind":"root"}},"access":"deny"}

The only intended deny rules visible alongside these were .env protections. A custom profile with explicit workspace roots allowed the task to start, which further isolates this to effective-profile compilation/state rather than the file itself.

What steps can reproduce the bug?

1. In the macOS desktop app, open a trusted local project that contains a readable AGENTS.md.
2. Use a multi-folder local environment/workspace.
3. Select Full Access for the task.
4. Start a task or restart a turn so the environment is initialized and project instructions are loaded.
5. Observe that startup can fail before the first model turn with the AGENTS.md EPERM above.
6. Inspect the task rollout/effective permissions: the selected profile is :danger-full-access, while the compiled managed profile contains both root write and root deny.

What is the expected behavior?

Full Access should compile to an effective profile that can read the trusted workspace's AGENTS.md. A root deny must not be introduced for the same root that Full Access grants. If a managed policy overrides Full Access, the UI and error should identify the overriding policy and its provenance instead of presenting Full Access as active.

Additional information

The failure reproduced twice on September 10, 2026:

• 2026-09-10T17:36:22.134Z, task 01a08939-98be-7e61-a365-3eafb05079c4, turn 01a08c64-59d8-72b1-b8a7-c3f012e78445
• 2026-09-10T17:59:07.553Z, task 01a08c36-04e3-7f73-a9ff-db04f8dbc0be, turn 01a08c79-2f8b-72f2-8773-bc1d652f2193

Related but distinct: #40937 covers an intentionally restricted custom profile whose read roots exclude the workspace. This report concerns Full Access being selected while the generated effective profile denies the workspace root.

No raw logs, repository contents, account identifiers, or credentials are included in this public report.

Reproduce the failure using a trusted multi-folder workspace, Full Access, and a readable AGENTS.md, then inspect the task rollout and compiled managed profile. Trace how the Full Access selection becomes root write and deny entries; done means Full Access permits AGENTS.md startup or clearly reports the overriding policy and provenance.