Codex App denies Docker Unix socket access while CLI allows it with same config

[federico-vitale]

What version of the Codex App are you using (From “About Codex” dialog)?

26.519.81530 (3178)

What subscription do you have?

Business

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Codex App and Codex CLI behave differently when accessing the local Docker Unix socket with the same user config, same project config, same working directory, and same Docker context.

In Codex CLI, the following command succeeds without approval:

docker ps --format '{{.Names}}'

In Codex App, the same command fails without approval:

permission denied while trying to connect to the docker API at unix:///Users/<user>/.docker/run/docker.sock

The Docker context points to that exact socket:

docker context show
# desktop-linux

docker context inspect "$(docker context show)" --format '{{json .Endpoints.docker.Host}}'
# "unix:///Users/<user>/.docker/run/docker.sock"

The socket exists:

ls -la /Users/<user>/.docker/run/docker.sock
# srwxr-xr-x@ ... /Users/<user>/.docker/run/docker.sock

/var/run/docker.sock is only a symlink to the same socket:

ls -la /var/run/docker.sock
# /var/run/docker.sock -> /Users/<user>/.docker/run/docker.sock

Both runtimes appear to load the same user config and project config, but the App still denies access to the Docker Unix socket without approval, while the CLI allows it.

What steps can reproduce the bug?

Environment:

• macOS Apple Silicon
• Codex CLI version: 0.134.0
• Codex installed via Homebrew
• Docker Desktop with context desktop-linux
• Docker socket: unix:///Users/<user>/.docker/run/docker.sock
• Project path: /Users/<user>/Documents/Dev/<project>

User config excerpt from ~/.codex/config.toml:

default_permissions = "default"

[permissions.default]
extends = ":workspace"

[permissions.project-workspace.network.unix_sockets]
"/Users/<user>/.docker/run/docker.sock" = "allow"

[projects."/Users/<user>/Documents/Dev/<project>"]
trust_level = "trusted"

Project config excerpt from <project-path>/.codex/config.toml:

approval_policy = "on-request"
default_permissions = "project-workspace"

[permissions.project-workspace]
extends = ":workspace"

[permissions.project-workspace.network]
enabled = true

[permissions.project-workspace.network.domains]
"*" = "allow"

[permissions.project-workspace.network.unix_sockets]
"/Users/<user>/.docker/run/docker.sock" = "allow"

Steps to reproduce:

1. Open a terminal.
2. cd /Users/<user>/Documents/Dev/<project>
3. Start Codex CLI from that directory.
4. Ask Codex CLI to run the following command without escalation:

docker ps --format '{{.Names}}'

5. The command succeeds in Codex CLI without approval.
6. Open Codex App in the same project directory.
7. Ask Codex App to run the same command without escalation:

docker ps --format '{{.Names}}'

8. The command fails in Codex App with:

permission denied while trying to connect to the docker API at unix:///Users/<user>/.docker/run/docker.sock

9. If approval/escalation is granted in Codex App, the same command succeeds.

What is the expected behavior?

Codex App and Codex CLI should behave consistently when using the same user config, same project config, same trusted project path, same Docker context, and same permission profile.

Expected behavior: if Codex CLI can access the allowlisted Docker Unix socket without approval, Codex App should also be able to access it without approval.

Alternatively, if Codex App intentionally applies a stricter sandbox than Codex CLI, that difference should be documented or exposed clearly in diagnostics.

Additional information

Diagnostic information:

codex doctor --json run from <project-path> reports config loading successfully:

{
  "CODEX_HOME": "/Users/<user>/.codex",
  "config.toml": "/Users/<user>/.codex/config.toml",
  "config.toml parse": "ok",
  "cwd": "/Users/<user>/Documents/Dev/<project>",
  "model": "gpt-5.5",
  "model provider": "openai"
}

Sandbox helper details reported from the same project directory:

{
  "approval policy": "OnRequest",
  "codex-linux-sandbox helper": "none",
  "filesystem sandbox": "restricted",
  "network sandbox": "enabled"
}

When the same diagnostics are run from Codex App, the App can read both:

~/.codex/config.toml
<project-path>/.codex/config.toml

The issue does not appear to be caused by Docker context, missing Docker CLI, missing socket, or /var/run/docker.sock vs user Docker socket mismatch:

docker context inspect "$(docker context show)" --format '{{json .Endpoints.docker.Host}}'
# "unix:///Users/<user>/.docker/run/docker.sock"

ls -la /var/run/docker.sock
# /var/run/docker.sock -> /Users/<user>/.docker/run/docker.sock

The same command succeeds in Codex App after approval/escalation, so Docker itself is reachable. The failure only happens in the non-escalated Codex App runtime.