# \[Bug\]: Codex \.env read-deny entries disappear from supplied permissions after Auto → Full access → Auto · Issue \#20266 · pingdotgg/t3code

[View on GitCafe](https://git.cafe/pingdotgg/t3code/issues/20266)

Repository: [pingdotgg/t3code](https://git.cafe/pingdotgg/t3code)

Visibility: public

State: backlog

Priority: 0

## Description

[Discussion and activity](https://git.cafe/pingdotgg/t3code/issues/20266)

---

### Before submitting

- [x] I searched existing issues and did not find a duplicate.
- [x] 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.

1. Open T3 Code and select a local project using that permission profile.
2. Create a **new thread**, select **Codex**, and choose **Auto** in the permissions dropdown.
3. Send a message asking Codex to list the `.env` and `.env*` read-deny entries in its latest injected permission instructions, without accessing those files. Record the result. Both entries were listed in this reproduction.
4. Change the same thread's permissions dropdown to **Full access** and send a follow-up message so the new mode takes effect.
5. Change the dropdown back to **Auto** and send another message asking Codex to list the `.env` and `.env*` read-deny entries in its **latest** injected permission instructions, separately from older instructions in the conversation. Do not access the files.
6. 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 `.env` and `.env*` read denials

### Logs or stack traces

Sanitized summaries of the supplied permission instructions reported during the test:

```text
Fresh Auto:
  sandbox mode: workspace-write
  denied reads:
    /path/to/project/**/.env
    /path/to/project/**/.env*

Auto after Full access:
  sandbox mode: workspace-write
  .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
default_permissions = "env-protected"

[permissions.env-protected]
extends = ":workspace"

[permissions.env-protected.filesystem.":workspace_roots"]
"**/.env" = "deny"
"**/.env*" = "deny"
```

Use permission profiles without legacy `sandbox_mode` / `[sandbox_workspace_write]` settings, which can override them. See the [Codex permissions documentation](https://learn.chatgpt.com/docs/permissions).

### 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**