Codex desktop app ignores custom default_permissions profile for read-only filesystem with network access

Summary

The Codex desktop app does not apply a custom permissions profile configured through default_permissions. New desktop threads continue to use readOnly + networkAccess:false, even after fully restarting the app.

The same permissions profile works correctly when explicitly selected through the Codex CLI with codex sandbox -P net-readonly.

Environment

Codex desktop app / bundled CLI: codex-cli 0.140.0-alpha.2
OS: macOS 14.6, arm64
Approval policy: on-request
Project trust level: trusted

Configuration

approval_policy = "on-request"
approvals_reviewer = "user"
default_permissions = "net-readonly"

[permissions.net-readonly]
description = "Allow network, but require approval for writes"
extends = ":read-only"

[permissions.net-readonly.network]
enabled = true
mode = "limited"

[permissions.net-readonly.network.domains]
"*" = "allow"

Steps to reproduce

Add the configuration above to ~/.codex/config.toml.
Fully restart the Codex desktop app.
Create a new desktop thread in a trusted project.
Run a network request such as curl -I https://example.com.
Attempt to write a file.

Actual behavior

Desktop thread permission snapshot is created as:

sandboxPolicy: readOnly
networkAccess: false

Network requests fail because DNS/network access is denied.
File writes correctly require approval.
Restarting the app and creating new threads does not apply the configured profile.

Expected behavior

The desktop app should apply default_permissions = "net-readonly" to new threads, resulting in:

Read-only filesystem, with writes requiring approval.
Network access controlled by the profile's domain allowlist.

CLI verification

The profile itself is valid and works when explicitly selected:

codex sandbox -P net-readonly curl -I https://example.com

This successfully returns HTTP 200, confirming the issue appears specific to how the desktop app resolves or passes the default permissions profile.

Additional diagnostic information

codex doctor --json reports the desktop thread sandbox as restricted with the network sandbox enabled. The desktop app global state records newly created affected threads as readOnly + networkAccess:false.

@lns480672-eng

@lns480672-eng When I added a second profile suddenly the profiles appeared in the Codex desktop app and I could select the correct permission profile. Maybe this helps you also?

Adding another data point from macOS/Codex Desktop.

Environment:

Codex Desktop 26.623.42026
codex-cli 0.142.3
macOS Darwin 25.5.0 arm64

Observed behavior:

With the app permission selector set to Custom, and config using the new profile key:

default_permissions = ":danger-full-access"
approval_policy = "on-request"
approvals_reviewer = "auto_review"

new sessions still behaved as if they were effectively read-only. Workspace writes, $TMPDIR, and /tmp writes failed with Operation not permitted; zsh heredoc failed with can't create temp file for here document; and git status failed while trying to create /tmp/xcrun_db-*.

In the same affected session, manually switching the app selector to Full access made those write/heredoc/git operations work.
Switching back to Custom reproduced the read-only behavior.
Replacing the new profile key with the legacy config:

sandbox_mode = "danger-full-access"
approval_policy = "on-request"
approvals_reviewer = "auto_review"

then fully restarting Codex App made Custom work correctly in both a new session and the previously affected session.

This looks consistent with Desktop Custom not applying the default_permissions profile path in this case, while the legacy sandbox_mode path still works.

macOS desktop app cannot reach my local infrastructure despite full access

I’m using Codex from the ChatGPT desktop app on macOS to work across several local projects. Those projects need to talk to services on my home/LAN environment, including Forgejo, Proxmox, and a Forgejo Runner.

Everything works normally when I run the same commands from the native macOS Terminal. The issue only appears when the command is launched from Codex.

I initially suspected DNS, Tailscale, or a local firewall issue, but the evidence points instead to the Codex execution environment blocking private LAN traffic.

Codex can access the public Internet and Tailscale successfully, but it cannot reach any RFC1918 LAN address.

For example, my Forgejo SSH endpoint is available at:
192.168.1.94:2222

From a native macOS Terminal, it works. From Codex, it fails immediately:

nc: connectx to 192.168.1.94 port 2222 (tcp) failed: No route to host
ssh: connect to host 192.168.1.94 port 2222: No route to host
ping: sendto: No route to host

This is not limited to Forgejo. The same happens when contacting the local gateway:
192.168.1.1: No route to host

So the problem affects the entire local network, not one particular service.

Why this does not look like a network configuration problem

The host itself has a valid route to the target:

route to: 192.168.1.94
interface: en0

ARP resolution is also available for the device on the LAN.

At the same time:

public Internet access from Codex works;
Tailscale connectivity from Codex works;
the exact same local endpoints are reachable from native Terminal;
the macOS Local Network permission for codex is enabled;
I fully restarted the app after enabling that permission.

This suggests that the Codex command runner is being restricted separately from the host network stack.

Environment

macOS: 27.0, arm64
ChatGPT/Codex desktop app: 26.727.51351
Bundled Codex CLI: 0.146.0-alpha.9.2
Bundle identifier: com.openai.codex
Execution host identity: codex-code-mode-host

My relevant Codex configuration is:

approval_policy = "never"
sandbox_mode = "danger-full-access"

Despite that, codex doctor --json reports:

filesystem sandbox: unrestricted
network sandbox: enabled

That is the key detail: the filesystem is unrestricted, but the network sandbox remains enabled.

Reproduction

Have a service available on a private LAN IP address.
Verify it is reachable from native macOS Terminal.
Open a local Codex desktop-app chat.
Run a connection test from Codex:

nc -vz -w 5 192.168.1.94 2222
ssh -o BatchMode=yes -o ConnectTimeout=5 forgejo-local exit
ping -c 1 -W 1000 192.168.1.94

Expected behavior

With:
sandbox_mode = "danger-full-access"

I would expect Codex-launched commands to have the same LAN reachability as commands launched from Terminal, including access to private addresses such as 192.168.1.x.

This is especially important for local development workflows involving self-hosted Git, virtualization, CI runners, NAS devices, internal APIs, and home-lab infrastructure.

Additional observation

Docker commands also time out from Codex when they try to reach Docker Desktop’s Unix socket:

curl --unix-socket ~/.docker/run/docker.sock --max-time 5 http://localhost/_ping

I cannot yet tell whether Docker Desktop itself is unhealthy or whether the same Codex sandbox/proxy policy is preventing access to the Unix socket. Given the LAN behavior, I suspect the latter may be involved.

I can reproduce what appears to be the same underlying Codex Desktop network-permission problem on macOS, but in my case it also occurs when Network / Full Access is explicitly enabled in the Desktop UI.

Environment

Codex Desktop / ChatGPT app version: 26.803.41515
App release date: Aug 7, 2026
macOS Tahoe 26.2
MacBook Air 13", M4 (2025)
Apple M4
16 GB RAM
Network / Full Access enabled in the Codex Desktop UI
GitHub CLI works normally in the host macOS Terminal

Reproduction inside Codex Desktop

In a Codex Desktop local session:

printf 'NETWORK_DISABLED=%s\n' "${CODEX_SANDBOX_NETWORK_DISABLED:-unset}"
printf 'HOME=%s\n' "$HOME"
printf 'GH_CONFIG_DIR=%s\n' "${GH_CONFIG_DIR:-unset}"

echo '--- DNS ---'
dscacheutil -q host -a name github.com || true

echo '--- HTTPS ---'
curl -I --max-time 5 https://api.github.com || true

echo '--- GH ---'
gh auth status --hostname github.com || true

Result:

NETWORK_DISABLED=1
HOME=/Users/pg
GH_CONFIG_DIR=unset

--- DNS ---

--- HTTPS ---
curl: (6) Could not resolve host: api.github.com

--- GH ---
github.com
  X Failed to log in to github.com account piergiorgio1999 (default)
  - Active account: true
  - The token in default is invalid.

The important signal is:

CODEX_SANDBOX_NETWORK_DISABLED=1

even though Network / Full Access is enabled in the Codex Desktop UI.

Control test outside Codex

On the same Mac, same user, in the normal macOS Terminal:

CODEX_SANDBOX_NETWORK_DISABLED=unset
GH_TOKEN=<unset>
GITHUB_TOKEN=<unset>
GH_HOST=<unset>
HTTP_PROXY=<unset>
HTTPS_PROXY=<unset>
ALL_PROXY=<unset>

GitHub CLI authentication works:

github.com
  ✓ Logged in to github.com account piergiorgio1999 (keyring)
  - Active account: true
  - Git operations protocol: https

Network connectivity works:

curl -I https://api.github.com
HTTP/2 200

GitHub Git access also works:

git ls-remote https://github.com/piergiorgio1999/agent-template.git HEAD
30ee11236b4f4750fb802024f99955f84f7f0bed HEAD

So on the host:

DNS works
HTTPS to GitHub works
gh authentication works
git ls-remote works
no GH_TOKEN, GITHUB_TOKEN, GH_HOST or proxy environment overrides are present

while commands executed inside Codex Desktop have networking disabled.

Fresh-session reproduction outside the project

I then created a second fresh Codex Desktop local session outside the original repository/project and repeated the diagnostic.

It produced the same result:

NETWORK_DISABLED=1
curl: (6) Could not resolve host: api.github.com

This substantially rules out repository-specific configuration as the cause.

The failure follows the Codex Desktop execution environment/session instead.

Expected behavior

When Network / Full Access is enabled in the Codex Desktop UI, newly-created local sessions should not receive:

CODEX_SANDBOX_NETWORK_DISABLED=1

and commands executed by Codex should be able to perform permitted DNS/network operations.

Impact

This is particularly problematic for agentic GitHub workflows.

In my case it caused a release workflow to fail closed because Codex could not:

query GitHub through gh;
verify remote CI state from the shell;
verify tags/releases;
perform release-related GitHub operations.

The host itself had completely normal GitHub connectivity throughout.

It can also lead to a misleading diagnosis: gh auth status reports the token as invalid inside Codex, while the same keyring-backed credentials authenticate successfully immediately outside Codex.

For that reason I would consider the gh authentication message a secondary/unconfirmed symptom until it can be reproduced inside a Codex sandbox with working network access.

Summary

The reproducible discrepancy is:

Codex Desktop UI:
Network / Full Access = enabled

Fresh Codex Desktop sandbox:
CODEX_SANDBOX_NETWORK_DISABLED=1
DNS / HTTPS = blocked

Same Mac, normal Terminal:
DNS = working
HTTPS = working
gh auth = working
git remote access = working

Reproduced on Aug 11, 2026.

This appears to be a Codex Desktop permission/sandbox propagation issue rather than a GitHub, macOS network, or repository configuration problem.

Additional configuration evidence:

Codex Desktop is currently configured in the UI with:

Approval policy: Never ask for approval
Sandbox: Full access
Web search: Live
Codex dependencies: enabled

The relevant persisted config.toml settings are also:

approval_policy = "never"
sandbox_mode = "danger-full-access"

[projects."/Users/pg"]
trust_level = "trusted"

[projects."/Users/pg/agent-template"]
trust_level = "trusted"

There is no CODEX_SANDBOX_NETWORK_DISABLED assignment in my config.toml.

The configuration also does not set GH_TOKEN, GITHUB_TOKEN, HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY.

Despite both the Desktop UI and the persisted configuration explicitly allowing full access, fresh Codex Desktop sessions still start with:

CODEX_SANDBOX_NETWORK_DISABLED=1

and DNS resolution from the Codex command environment fails.

This was reproduced in multiple fresh local sessions, including a session opened outside the original repository/project.

So the observed state is:

config.toml:
sandbox_mode = "danger-full-access"
            ✅

Codex Desktop UI:
Sandbox = Full access
            ✅

Fresh session runtime:
CODEX_SANDBOX_NETWORK_DISABLED=1
            ❌
DNS / HTTPS from shell fail

This strongly suggests that the effective runtime sandbox/network policy is not matching either the persisted user configuration or the Desktop UI configuration.

For completeness, the host macOS Terminal continues to have normal DNS/HTTPS connectivity and valid GitHub CLI authentication while the Codex Desktop sandbox is affected.

I can reproduce a related Desktop configuration-propagation failure on Linux with a remote SSH workspace.

Environment

Subscription: ChatGPT Pro
ChatGPT Desktop workspace version: 26.909.12148
Remote backend: Debian Linux in an unprivileged Proxmox LXC
Remote Codex CLI: 0.154.0
App-server: codex -c features.code_mode_host=true app-server --listen unix://

Desktop configuration

Both configuration sources in ChatGPT Desktop report:

User config: Full access, approval policy On request
Admin config: Full access, approval policy On request

The admin view is locked, but it also explicitly displays Full access; this is not an Enterprise/Business workspace override.

Actual behavior

New remote Desktop tasks still receive a managed, network-restricted permission profile. Capturing a long-running task (sleep 180) shows:

codex-linux-sandbox --permission-profile ... "network":"restricted"
bwrap ... --unshare-user --unshare-pid --unshare-ipc --unshare-net --cap-drop ALL

The task process has:

NoNewPrivs: 1
Seccomp: 2
Seccomp_filters: 2

and cannot create sockets:

nslookup px.woz.nz
# socket(): Operation not permitted

The remote host and persistent app-server are not the problem:

sudo nsenter -t <app-server-pid> -n -- getent hosts px.woz.nz
# 192.168.1.64 px.woz.nz

The normal SSH shell on the same host also resolves and reaches the LAN normally.

Expected behavior

A new Desktop task created after selecting Full access should not receive "network":"restricted" or Bubblewrap --unshare-net.

CLI comparison / workaround

Starting a direct remote CLI session works:

codex --sandbox danger-full-access --ask-for-approval on-request

The same DNS/SSH checks then succeed. This suggests the failure is in Desktop's remote-task permission-profile propagation, rather than the Linux host, LXC, DNS, or Codex app-server.

Happy to provide the full sanitized process tree or diagnostic bundle if useful.

Related reproduction on macOS desktop with local execution. Feedback ID: 01a1468a-5dae-718a-9f82-f4404a5640e7.

The saved custom profile enables networking and network_proxy, with api.cloudflare.com and dash.cloudflare.com explicitly allowed. The filesystem boundary guard passes, but Wrangler 4.121.0 repeatedly exits 1 with:

Unable to resolve Cloudflare's API hostname (api.cloudflare.com or dash.cloudflare.com).

The agent still receives a restricted-network context. The composer shows Ask for approval, Approve for me, and Full access; no named profile selector is visible. What supported diagnostic can identify the effective profile and proxy without relaxing filesystem restrictions?

No upload occurred. The controlling policy and root cause remain unconfirmed.

Navigation Menu

Repository navigation

Codex desktop app ignores custom default_permissions profile for read-only filesystem with network access #28281

Summary

Environment

Configuration

Steps to reproduce

Actual behavior

Expected behavior

CLI verification

Additional diagnostic information

Why this does not look like a network configuration problem

Environment

Reproduction

Expected behavior

Additional observation

Environment

Reproduction inside Codex Desktop

Control test outside Codex

Fresh-session reproduction outside the project

Expected behavior

Impact

Summary

Environment

Desktop configuration

Actual behavior

Expected behavior

CLI comparison / workaround

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Codex desktop app ignores custom default_permissions profile for read-only filesystem with network access #28281

Description

Summary

Environment

Configuration

Steps to reproduce

Actual behavior

Expected behavior

CLI verification

Additional diagnostic information

Activity

foxylion commented on Jun 23, 2026

litaochenbit commented on Jun 28, 2026

Julian1984 commented on Aug 1, 2026

Why this does not look like a network configuration problem

Environment

Reproduction

Expected behavior

Additional observation

piergiorgio1999 commented on Aug 11, 2026

Environment

Reproduction inside Codex Desktop

Control test outside Codex

Fresh-session reproduction outside the project

Expected behavior

Impact

Summary

piergiorgio1999 commented on Aug 11, 2026

iamwoz commented on Sep 12, 2026

Environment

Desktop configuration

Actual behavior

Expected behavior

CLI comparison / workaround

doorlease commented on Oct 16, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions