Codex Desktop on macOS blocks 1Password CLI desktop transport, including approved escalated execution

Component

• Codex Desktop local task command execution
• macOS Seatbelt sandbox and approval escalation path
• Third-party integration: 1Password CLI desktop app integration

Environment

• ChatGPT desktop app: 26.911.61220 (build 9647)
• Bundled Codex CLI: codex-cli 0.155.0-alpha.2.6
• macOS: 27.0 (build 26A428)
• Architecture: arm64
• 1Password app: 8.12.36
• 1Password CLI: 2.38.1

The documented compatibility path /Applications/Codex.app/Contents/Resources/codex is not present on this installation. The bundled binary is at /Applications/ChatGPT.app/Contents/Resources/codex.

Summary

On this Mac, the 1Password app and CLI are installed and the 1Password setting Integrate with 1Password CLI is enabled. The desktop transport works from the normal host context, and the 1Password SSH agent is independently available through its exact Unix socket.

Inside a local Codex Desktop task, however, the same op CLI cannot connect to the 1Password desktop app. The failure reproduces in both an existing task and a newly created task. An explicitly approved, narrowly scoped elevated execution from the Codex task returns the same desktop connection failure.

This appears to be a Codex Desktop command-runtime boundary for the macOS XPC/Mach transport used by 1Password, rather than a missing or broken 1Password installation.

Steps to reproduce

1. On macOS, install and unlock 1Password and enable Settings > Developer > Integrate with 1Password CLI.

2. Install the 1Password CLI and confirm its version with:

   op --version
   

3. Confirm that the 1Password desktop integration is reachable from a normal host terminal using a metadata-only command.

4. Open a local task in Codex Desktop.

5. From the task command runtime, run a metadata-only desktop-auth check such as:

   op --cache=false account list --format=json
   

6. Observe that the command fails before returning account metadata.

7. Approve a narrowly scoped elevated execution of the same absolute op binary and repeat the metadata-only check.

8. Create a fresh local Codex task and repeat the check.

Actual result

The sandboxed and approved elevated task executions both fail with the equivalent of:

1Password CLI couldn't connect to the 1Password desktop app

A names-only diagnostic reports:

status: attention_required
op_desktop_access: desktop_transport_unreachable
blocking_check: op_desktop_access
1Password app: present
1Password CLI: present
SSH agent: available
Codex permission configuration: aligned

The same result reproduces in a fresh task. No vaults, item identifiers, account identifiers, or secret values were read or included in this report.

Expected result

One of the following should happen:

1. An explicitly approved, narrowly scoped elevated op command can use the same user-approved 1Password desktop transport available to the normal host terminal.
2. Codex provides a least-privilege permission mechanism for the required macOS XPC/Mach service.
3. Codex detects this unsupported transport and returns a specific actionable error instead of making the failure look like a broken 1Password installation.

Additional observations

• Reinstalling 1Password is not indicated: the application bundle is present, its version is readable, and host-side desktop acceptance succeeds.
• Reindexing Spotlight and re-registering the app with LaunchServices restored host discovery but did not change the Codex task result.
• A precise Unix-socket allowlist is sufficient for the 1Password SSH agent, but it does not affect the desktop CLI transport.
• Current Codex permission profiles document filesystem, network, and Unix-socket controls, but no narrow Mach/XPC service allowlist.
• Broad danger-full-access is not an acceptable workaround for credential access. In this case, the approved elevated attempt did not restore the desktop transport anyway.

Related issues found, but not exact duplicates

• #23505: macOS Seatbelt sandbox blocks libproc/sysmon process listing describes the same absence of a narrow Mach service allowlist, but for a different service.
• #21292: Playwright Chromium fails in Codex Desktop macOS sandbox with MachPortRendezvousServer permission denied is another Mach-port sandbox failure, but its escalated path succeeds.
• #32081: Add secure 1Password support to the Codex integrated browser concerns browser autofill, not op CLI desktop transport.

Requested investigation

Please compare the normal macOS host execution context with both the sandboxed and approved elevated command paths in Codex Desktop, specifically for the 1Password CLI desktop XPC/Mach transport. Please also clarify whether this integration is intentionally unsupported and, if so, expose a stable reason code and document the supported credential-consumer pattern.

Start with the Codex Desktop local task command runtime and compare the normal host, sandboxed, and approved elevated paths on macOS. Reproduce the metadata-only op --cache=false account list --format=json check, then inspect the Seatbelt approval and permission configuration described in the issue. Done means the supported behavior is established and the failure has an actionable, stable explanation or documented limitation.