Repository navigation
Desktop app functions.exec_command honors custom file permissions but not allow_local_binding #23973
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Version 26.519.22136 (3003)
What subscription do you have?
Business
What platform is your computer?
Darwin 25.5.0 arm64 arm
What issue are you seeing?
In the desktop app, using Custom (config.toml) permissions, functions.exec_command appears to use a permission model that partially honors the custom profile but still blocks localhost listener binding even when allow_local_binding = true is set and works in CLI.
With the same repo-local custom permission profile:
- both CLI and desktop app honor an explicit file deny
- both can still read other allowed workspace files
- but only CLI honors
allow_local_binding = true - desktop app still rejects localhost listener binding for
functions.exec_command
What steps can reproduce the bug?
Config used
default_permissions = "default-dev"
approval_policy = "on-request"
[permissions.default-dev.network]
enabled = true
mode = "limited"
allow_local_binding = true
[permissions.default-dev.filesystem]
":minimal" = "read"
"/path/to/project/README.md" = "none"
":workspace_roots" = "write"
"/tmp/" = "write"
"/private/tmp/" = "write"
"/private/var/folders/" = "write"CLI behavior
Standalone CLI:
codex-cli 0.133.0/statusshowedProfile default-dev
Probes:
python3 -S -c "from pathlib import Path; p=Path('/path/to/project/README.md'); print('EXISTS', p.exists()); print('HEAD', p.read_text().splitlines()[0])"
python3 -S -c "from pathlib import Path; p=Path('/path/to/project/docs/testing.md'); print('EXISTS', p.exists()); print('HEAD', p.read_text().splitlines()[0])"
python3 -S -c "import socket; s=socket.socket(); s.bind(('127.0.0.1', 0)); print('BOUND', s.getsockname()[1])"Results:
- denied file:
PermissionError: [Errno 1] Operation not permitted - allowed control file: readable
- localhost bind: succeeds, e.g.
BOUND 56711
Desktop app behavior
Desktop app:
Codex.app 26.519.22136- embedded
codex-cli 0.133.0-alpha.1
With Custom (config.toml) selected and after restart, equivalent probes produced:
- denied file:
PermissionError - allowed control file: readable
- localhost bind: still fails with
PermissionError: [Errno 1] Operation not permitted
What is the expected behavior?
If the desktop app exposes functions.exec_command under Custom (config.toml), it should honor allow_local_binding = true the same way the CLI does.
If that tool is intentionally sandboxed differently from the configured profile, that difference should be surfaced clearly in the UI and documented.
Additional information
What this proves
The desktop app is not ignoring custom permissions entirely. It is applying at least part of the custom profile to functions.exec_command, because the explicit file deny is enforced.
The mismatch is narrower:
- custom file permissions are honored
allow_local_binding = trueis not honored forfunctions.exec_commandin the desktop app- the same profile works correctly in the standalone CLI
Activity
jshaofa-ui commentedon May 22, 2026
Proposed Solution: Desktop App
allow_local_bindingNot HonoredRoot Cause
The Desktop app adds an additional sandboxing layer that overrides
config.tomlnetwork permissions. File permissions correctly read the custom profile, but the network permission path uses a hardcoded deny-list for localhost binding, ignoringallow_local_binding = true.Fix
allow_local_bindingfrom TOML in the network permission pathNetworkPermissionsfrom configNetworkPolicybefore allowing socket bindKey Code Change
Full solution:
solutions/codex-23973-desktop-allow-local-binding-fix.mdborek504 commentedon Sep 13, 2026
Additional current data point from a newer Codex Desktop build on macOS:
26.825.51511(build7377)0.151.0-alpha.7.2socket.bind(("127.0.0.1", 0))PermissionError: [Errno 1] Operation not permittedbeforelisten()orconnect()The effective task environment reported
CODEX_NETWORK_ALLOW_LOCAL_BINDING=0; in this test we intentionally did not enable the broader boolean because the requirement is a project-scoped, loopback-only ephemeral listener permission as proposed in #35768. Therefore this data point does not independently prove the exactallow_local_binding=truemismatch reported here, but it confirms that the same practical Desktop/Seatbelt loopback-bind blocker persists on a substantially newer build.A supported least-privilege solution would allow only
127.0.0.1(and optionally::1) on an OS-assigned ephemeral port, without granting non-loopback listeners or additional outbound access to local/private-network services. No sandbox bypass or unrestricted networking is requested.