Codex Desktop Full access enabled, but new chats still launch with network disabled

Codex
1

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?

2

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

The interesting part is that:

  • global config shows network_access = true

  • but newly created threads still persist sandboxPolicy.networkAccess:false

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​:face_with_monocle:

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