›_ Codex Issues
Codex Issues / #28281

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

Open 💬 5 comments Opened Jun 15, 2026 by lns480672-eng

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

  1. Add the configuration above to ~/.codex/config.toml.
  2. Fully restart the Codex desktop app.
  3. Create a new desktop thread in a trusted project.
  4. Run a network request such as curl -I https://example.com.
  5. 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.

View original on GitHub ↗

5 Comments

foxylion · 2 months ago

@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?

litaochenbit · 2 months ago

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.

Julian1984 · 26 days ago

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

  1. Have a service available on a private LAN IP address.
  2. Verify it is reachable from native macOS Terminal.
  3. Open a local Codex desktop-app chat.
  4. 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.

piergiorgio1999 · 16 days ago

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.

piergiorgio1999 · 16 days ago

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.