Homebrew Codex CLI cannot use Computer Use, while Codex.app-bundled CLI works

What version of Codex CLI is running?

Homebrew CLI: codex-cli 0.125.0

App-bundled CLI control case: codex-cli 0.125.0-alpha.3

What subscription do you have?

ChatGPT Pro

Which model were you using?

gpt-5.4-mini for the minimal codex exec probe. The same issue also occurs from an interactive CLI session.

What platform is your computer?

Darwin 25.4.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

Ghostty 1.3.1

What issue are you seeing?

Computer Use is unusable from the Homebrew-installed Codex CLI, but works from the Codex.app-bundled CLI on the same machine with the same Computer Use plugin/cache and macOS permissions.

The Homebrew CLI path fails even for the lowest-risk Computer Use call, list_apps, with:

Apple event error -10000: Sender process is not authenticated

The app-bundled CLI path succeeds for the same probe.

This appears related to #18507, but the distinct repro here is the launch/install path split:

• /opt/homebrew/bin/codex fails to use Computer Use.
• /Applications/Codex.app/Contents/Resources/codex succeeds.
• Same machine, same terminal, same ~/.codex config, same computer-use@openai-bundled plugin cache, and same macOS TCC permissions.

What steps can reproduce the bug?

1. Install/run Codex CLI via Homebrew so codex resolves to /opt/homebrew/bin/codex.
2. Ensure the bundled Computer Use plugin is enabled. In my case:

``text
computer-use@openai-bundled 1.0.758
``

codex mcp list shows the computer-use MCP server enabled and pointing at:

``text
~/.codex/plugins/cache/openai-bundled/computer-use/1.0.758/.../SkyComputerUseClient mcp
``

1. Ensure macOS permissions are granted for Computer Use. In my case:

• com.openai.sky.CUAService has Accessibility permission.
• com.openai.sky.CUAService has Screen Recording permission.
• The terminal app has Apple Events permission for com.openai.sky.CUAService.

1. Run this minimal Homebrew CLI probe:

``sh
/opt/homebrew/bin/codex exec -m gpt-5.4-mini -s danger-full-access --dangerously-bypass-approvals-and-sandbox \
'Use Computer Use only to call list_apps and report whether it worked. Do not click, type, scroll, open apps, or modify anything.'
``

1. Observe that computer-use/list_apps starts and then fails with:

``text
Apple event error -10000: Sender process is not authenticated
``

1. Run the same probe through the Codex.app-bundled CLI:

``sh
'/Applications/Codex.app/Contents/Resources/codex' exec -m gpt-5.4-mini -s danger-full-access --dangerously-bypass-approvals-and-sandbox \
'Use Computer Use only to call list_apps and report whether it worked. Do not click, type, scroll, open apps, or modify anything.'
``

1. Observe that computer-use/list_apps completes successfully and returns the app list.

What is the expected behavior?

The officially documented Homebrew-installed Codex CLI should be able to use the bundled Computer Use plugin when the plugin is enabled and the required macOS permissions are granted.

At minimum, the behavior should not differ this sharply between:

• /opt/homebrew/bin/codex
• /Applications/Codex.app/Contents/Resources/codex

If Computer Use is only supported from the Codex.app-bundled CLI/app launch context, the CLI/plugin UI should make that clear and avoid exposing a Computer Use MCP server that fails at runtime from the Homebrew CLI.

Additional information

Relevant local observations:

• Codex app version: 26.422.30944 (CFBundleVersion 2080)
• Homebrew CLI: /opt/homebrew/bin/codex -> codex-cli 0.125.0
• App-bundled CLI: /Applications/Codex.app/Contents/Resources/codex -> codex-cli 0.125.0-alpha.3
• Computer Use plugin: computer-use@openai-bundled 1.0.758
• Both CLI binaries are signed by Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2).
• The Homebrew binary reports Info.plist=not bound under codesign -dv --verbose=2.
• The Computer Use helper has Apple Events entitlement.
• The same failure occurs before targeting any specific app; it fails at list_apps.
• Computer Use cannot target terminal apps for safety reasons, but this is separate: the failing call is list_apps, not an attempt to automate the terminal.

Related issue/comment:

• #18507