Skip to content

Desktop app functions.exec_command honors custom file permissions but not allow_local_binding #23973

Open

Description

@RyanMentley

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
  • /status showed Profile 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 = true is not honored for functions.exec_command in the desktop app
  • the same profile works correctly in the standalone CLI

Activity

  1. added
    appIssues related to the Codex desktop app
    on May 22, 2026
  2. added
    bugSomething isn't working
    sandboxIssues related to permissions or sandboxing
    on May 22, 2026
  3. jshaofa-ui commented on May 22, 2026

    @jshaofa-ui

    Proposed Solution: Desktop App allow_local_binding Not Honored

    Root Cause

    The Desktop app adds an additional sandboxing layer that overrides config.toml network permissions. File permissions correctly read the custom profile, but the network permission path uses a hardcoded deny-list for localhost binding, ignoring allow_local_binding = true.

    Fix

    1. Unify Permission Application: Read allow_local_binding from TOML in the network permission path
    2. Network Section Parsing: Properly deserialize NetworkPermissions from config
    3. Permission Verification Gate: Check NetworkPolicy before allowing socket bind
    4. UI Transparency: Show effective network permissions in the permissions UI

    Key Code Change

    fn apply_network_permissions(&self, profile: &PermissionProfile) {
        match profile.network {
            Some(ref net) if net.allow_local_binding => {
                self.network_policy = NetworkPolicy::AllowLocalBinding(net.allowed_ports.clone());
            }
            _ => self.network_policy = NetworkPolicy::DenyLocalBinding,
        }
    }

    Full solution: solutions/codex-23973-desktop-allow-local-binding-fix.md

  4. borek504 commented on Sep 13, 2026

    @borek504

    Additional current data point from a newer Codex Desktop build on macOS:

    • Codex Desktop: 26.825.51511 (build 7377)
    • bundled CLI: 0.151.0-alpha.7.2
    • sandbox: Seatbelt
    • custom permission profile selected
    • minimal probe: socket.bind(("127.0.0.1", 0))
    • result: PermissionError: [Errno 1] Operation not permitted before listen() or connect()

    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 exact allow_local_binding=true mismatch 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingsandboxIssues related to permissions or sandboxing

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions