Reproduced on current main 8acbefe, using the web dev client on Linux x86_64 with Codex CLI 0.163.0 and the supplied permission profile. In one fresh thread, Auto included both deny globs; after Full access → Auto, the latest injected permission block omitted both. The saved native transcript confirms the difference. No protected files were read. Runtime transcript.
[Bug]: Codex .env read-deny entries disappear from supplied permissions after Auto → Full access → Auto#20266
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
Prerequisite: configure a Codex workspace permission profile with read denials for .env and .env* files. In this reproduction, the effective denied globs were /path/to/project/**/.env and /path/to/project/**/.env*; the project path is sanitized.
- Open T3 Code and select a local project using that permission profile.
- Create a new thread, select Codex, and choose Auto in the permissions dropdown.
- Send a message asking Codex to list the
.envand.env*read-deny entries in its latest injected permission instructions, without accessing those files. Record the result. Both entries were listed in this reproduction. - Change the same thread's permissions dropdown to Full access and send a follow-up message so the new mode takes effect.
- Change the dropdown back to Auto and send another message asking Codex to list the
.envand.env*read-deny entries in its latest injected permission instructions, separately from older instructions in the conversation. Do not access the files. - Compare the two Auto results. After the mode round trip, neither deny entry was listed in the latest supplied permission block.
The test used one newly created thread. No permission configuration was edited and the provider was not restarted between these steps.
Expected behavior
Returning to Auto should restore the configured .env and .env* read denials, and the supplied permission instructions should reflect them consistently with a fresh Auto thread.
Actual behavior
The fresh Auto thread listed both deny entries. After Auto → Full access → Auto, the latest supplied permission block no longer listed either entry, although the UI again showed Auto.
This report concerns the missing entries in the supplied permission instructions. Protected-file readability was not tested, so actual loss of enforcement has not been established. The origin of the change within T3, Codex, or their interaction remains unidentified.
Impact
Major degradation or frequent failure
Returning to the same UI permission setting does not restore the same stated secret-file protections. This makes it difficult to determine whether the configured read denials are still active and to trust the permission state shown for the thread.
Version or commit
- T3 server:
0.1.1-nightly.20261016.3203 - Codex CLI:
0.163.0 - Reproduced October 16, 2026
Environment
- macOS
26.6.2(25G83), Apple Silicon (arm64) - T3 Code Nightly desktop, local project, Codex provider
- Model:
gpt-6.1-sol, High reasoning effort - Initial workspace permission profile included explicit
.envand.env*read denials
Logs or stack traces
Sanitized summaries of the supplied permission instructions reported during the test:
text
| 1 | Fresh Auto: |
| 2 | sandbox mode: workspace-write |
| 3 | denied reads: |
| 4 | /path/to/project/**/.env |
| 5 | /path/to/project/**/.env* |
| 6 | |
| 7 | Auto after Full access: |
| 8 | sandbox mode: workspace-write |
| 9 | .env/.env* deny entries: absent from the latest supplied permission block |
Screenshots, recordings, or supporting files
Example for Codex's user config, ~/.codex/config.toml (or $CODEX_HOME/config.toml if set). Keep default_permissions at the top level; these rules apply under each workspace root.
toml
| 1 | default_permissions = "env-protected" |
| 2 | |
| 3 | [permissions.env-protected] |
| 4 | extends = ":workspace" |
| 5 | |
| 6 | [permissions.env-protected.filesystem.":workspace_roots"] |
| 7 | "**/.env" = "deny" |
| 8 | "**/.env*" = "deny" |
Use permission profiles without legacy sandbox_mode / [sandbox_workspace_write] settings, which can override them. See the Codex permissions documentation.
Workaround
No verified in-place restoration. The fresh thread started directly in Auto initially listed both deny entries.
Note
GPT 6.1 Sol posting on behalf of Adam