I’m seeing a Codex Desktop permission mismatch where the UI and config show network/full access enabled, but new chats still launch with network disabled.

Environment:

• Codex Desktop: 0.133.0
• macOS app
• Date observed: May 28, 2026 PT

What I did:

1. Enabled Full access in Codex Desktop Settings.
2. Restarted Codex Desktop multiple times.
3. Created a new chat after the toggle and restart.
4. Checked the effective runtime environment.

Expected:

• New chats should launch with network access enabled.
• CODEX_SANDBOX_NETWORK_DISABLED should be absent.

Actual:

• New chats still show:
  CODEX_SANDBOX_NETWORK_DISABLED=1
• ~/.codex/config.toml contains:
  sandbox_mode = "workspace-write"
network_access = true
• But Codex’s persisted per-thread state still records the new thread with:
  sandboxPolicy.networkAccess:false
• The active thread DB also records:
  {"type":"workspace-write","network_access":false,...}

Impact:

• Some allowlisted commands like curl -sS --max-time ... or git -C ... can still reach GitHub, which makes diagnostics confusing.
• But normal sandboxed shell work sees network disabled.
• Project automation that correctly checks CODEX_SANDBOX_NETWORK_DISABLED refuses to run network-dependent finish/push steps.

This looks like Codex Desktop is not translating the Full access UI/config setting into the per-thread sandbox policy used when launching new chats.

Is there another setting or state file that controls heartbeat-thread-permissions-by-id[*].sandboxPolicy.networkAccess, or is this a Codex Desktop bug?

Well honestly this sounds more like a state propagation/persistence bug than user misconfiguration.

The interesting part is that:

And that makes it feel like the thread launcher is either:

• reading from a stale permission snapshot

• caching old sandbox metadata

• or using a separate state source entirely from ~/.codex/config.toml.

So the partial allowlisted network behavior probably explains the confusing diagnostics too, some commands bypassing the broader sandbox restriction makes it look “partially enabled” even though the effective sandbox policy is still false​

Wouldn’t surprise me if thread creation is persisting an older default policy somewhere internally instead of honoring the current desktop config.

This is still happening with the latest Codex (Mac Version 26.707.31428). Specifically, I updated and restarted Codex and in a new thread I asked it to run the following in a shell and return the output:

echo $CODEX_SANDBOX_NETWORK_DISABLED
curl -I https://www.google.com

The output returned was:

$ echo $CODEX_SANDBOX_NETWORK_DISABLED
1

$ curl -I https://www.google.com
curl: (6) Could not resolve host: www.google.com

So it appears that there is a problem running tasks (and scheduled automations). I’m not sure how these tasks have been able to run previously; I’ve been running into this issue off and on for the past few weeks but it had to work sometimes to create the automation in the first place.

Is this a known issue (obviously I’m not the only person running into it)?
Is there any workaround besides setting the sandbox to full access (which I don’t wish to do)?

Bump… Anyone? Is there an automated agent checking for unresolved issues? This should be reproducible and I’m not understanding why this isn’t a major blocking issue for more people (at least on the Mac).

Separately, but perhaps related, ChatGPT automations are also failing to communicate with Apple Mail via osascript and I’m wondering if this might be related to the networking issue. I’m not aware of any setting I can change to resolve either of these issues.