{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreig7wtk6asn35pwpunqf6jk24p43fbi3ge2p6t23oarwtd2nh42ffe",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3mmvssfbml5r2"
  },
  "path": "/t/codex-desktop-full-access-enabled-but-new-chats-still-launch-with-network-disabled/1381940#post_2",
  "publishedAt": "2026-05-28T10:18:45.000Z",
  "site": "https://community.openai.com",
  "textContent": "Well honestly this sounds more like a state propagation/persistence bug than user misconfiguration.\n\nThe interesting part is that:\n\n  * global config shows `network_access = true`\n\n  * but newly created threads still persist `sandboxPolicy.networkAccess:false`\n\n\n\n\nAnd that makes it feel like the thread launcher is either:\n\n  * reading from a stale permission snapshot\n\n  * caching old sandbox metadata\n\n  * or using a separate state source entirely from `~/.codex/config.toml`.\n\n\n\n\nSo 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​\n\nWouldn’t surprise me if thread creation is persisting an older default policy somewhere internally instead of honoring the current desktop config.",
  "title": "Codex Desktop Full access enabled, but new chats still launch with network disabled"
}