codex - 💡(How to fix) Fix Codex App denies Docker Unix socket access while CLI allows it with same config

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Root Cause

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:

Code Example

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

---

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

---

docker context show
# desktop-linux

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

---

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

---

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

---

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"

---

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"

---

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

---

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

---

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

---

{
  "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"
}

---

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

---

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

---

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
RAW_BUFFERClick to expand / collapse

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}}'
  1. The command succeeds in Codex CLI without approval.
  2. Open Codex App in the same project directory.
  3. Ask Codex App to run the same command without escalation:
docker ps --format '{{.Names}}'
  1. 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
  1. 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.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix Codex App denies Docker Unix socket access while CLI allows it with same config