macOS CLI: bundled Computer Use helper requests microphone permission without audio-input entitlement, then fails with "Apple event error -10000: Sender process is not authenticated"

Resolved 💬 11 comments Opened Apr 18, 2026 by Jorjon Closed May 31, 2026

What version of Codex CLI is running?

codex-cli 0.121.0

What subscription do you have?

ChatGPT Plus

Which model were you using?

gpt-5.4

What platform is your computer?

Darwin 24.6.0 arm64 arm

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

kitty 0.46.0

What issue are you seeing?

The bundled computer-use@openai-bundled plugin loads and the helper launches, but real Computer Use calls fail at runtime with:

Apple event error -10000: Sender process is not authenticated

This does not appear to be a normal missing Accessibility / Screen Recording setup issue.

I verified locally that:

  • features.apps = true is enabled
  • plugins."computer-use@openai-bundled".enabled = true
  • stale local computer-use@local overrides were removed
  • the helper app was installed/launched from the bundled plugin into ~/Applications/Codex Computer Use.app
  • Accessibility and Screen Recording are already granted to com.openai.sky.CUAService
  • the helper bundle has Apple Events automation entitlement
  • but the helper does not have com.apple.security.device.audio-input

During a fresh failing list_apps call, macOS TCC logs show the helper requesting microphone/audio permission and being denied immediately because the entitlement is missing.

Representative local TCC evidence:

  • service: kTCCServiceMicrophone
  • identifier: com.openai.sky.CUAService
  • error:

Prompting policy for hardened runtime; service: kTCCServiceMicrophone requires entitlement com.apple.security.device.audio-input but it is missing

After that, Codex still surfaces only:

Apple event error -10000: Sender process is not authenticated

So the user-facing error appears misleading. The helper seems to hit a denied audio/microphone TCC path first.

What steps can reproduce the bug?

  1. On macOS Apple Silicon, run codex from the terminal.
  2. Enable the bundled plugin in ~/.codex/config.toml:
[features]
apps = true

[plugins."computer-use@openai-bundled"]
enabled = true
  1. Install/launch the bundled helper once so com.openai.sky.CUAService is registered.
  2. Grant Accessibility and Screen Recording permissions to Codex Computer Use.
  3. Start a fresh Codex CLI session.
  4. Ask Codex to use Computer Use, for example: use computer use to list apps
  5. Observe failure:
  • tool returns Apple event error -10000: Sender process is not authenticated
  1. Check macOS unified logs / TCC logs around the failing call and observe a microphone/audio TCC denial for com.openai.sky.CUAService because com.apple.security.device.audio-input is missing.

What is the expected behavior?

If the helper does not require microphone/audio input for list_apps, it should not request it.

If it does require audio input, the bundled helper should ship with the correct entitlement and usage strings so TCC can grant it normally.

Either way, the failure should not surface only as Apple event error -10000 when the underlying blocked path is a TCC audio/microphone entitlement problem.

Additional information

This seems distinct from the current Computer Use issues:

  • #18258
  • #18404

In this case, the plugin is present and launches correctly; the failure happens after launch during runtime permission handling.

Additional local observations:

  • Public openai/codex appears to contain plugin discovery/plumbing for computer-use, but not the source for the proprietary helper bundle itself.
  • The bundled helper inspected here was:

~/.codex/plugins/cache/openai-bundled/computer-use/1.0.750/Codex Computer Use.app

  • The helper entitlements include Apple Events automation, but not audio-input entitlement.

View original on GitHub ↗

11 Comments

joeykrug · 3 months ago

Same issue

samuelkahessay · 3 months ago

I’m seeing the same user-visible failure, with some extra TCC evidence that may help narrow it down.

Repro still fails at runtime with:

computer-use list_apps -> Apple event error -10000: Sender process is not authenticated

What I verified locally:

  • bundled helper: computer-use@openai-bundled 1.0.750
  • com.openai.sky.CUAService already has system TCC grants for:
  • kTCCServiceAccessibility
  • kTCCServiceScreenCapture
  • I forced fresh AppleEvents prompts by launching the Codex app-server from both Ghostty and Terminal.app
  • macOS created allow rows for both:
  • kTCCServiceAppleEvents | com.mitchellh.ghostty | com.openai.sky.CUAService | auth=2
  • kTCCServiceAppleEvents | com.apple.Terminal | com.openai.sky.CUAService | auth=2

Even after accepting those prompts, list_apps still returns the same Apple event error -10000.

Most relevant tccd line from the failing Terminal-hosted attempt:

TCCDProcess: identifier=com.openai.sky.CUAService ... attempted to call TCCAccessRequest for kTCCServiceAccessibility without the recommended com.apple.private.tcc.manager.check-by-audit-token entitlement

I also saw the earlier AppleEvents attribution failure when Codex.app was treated as the responsible app:

service: kTCCServiceAppleEvents requires entitlement com.apple.security.automation.apple-events but it is missing for responsible={identifier=com.openai.codex ...}

So this looks consistent with the same -10000 surface error masking multiple underlying macOS permission/attribution failures, not just a missing user grant.

2001Y · 3 months ago

Reproduced on macOS with Codex CLI 0.121.0 after explicitly granting permissions to the exact bundled helper app Codex is actually launching.

What I verified locally:

  • Codex is launching the cache-side helper, not the app-bundled copy:
  • ~/.codex/plugins/cache/openai-bundled/computer-use/1.0.750/Codex Computer Use.app
  • The launched executable is:
  • ~/.codex/plugins/cache/openai-bundled/computer-use/1.0.750/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient mcp
  • Bundle identifiers / signing observed on that helper:
  • com.openai.sky.CUAService
  • com.openai.sky.CUAService.cli
  • TeamIdentifier: 2DC432GLL2

After adding the cache-side "Codex Computer Use.app" in System Settings and re-testing, a simple:

  • computer-use.list_apps({})

still fails with:

  • Apple event error -10000: Sender process is not authenticated

So in my case this is not resolved just by granting permissions to the actual helper app Codex is using.

jshaw · 3 months ago

seeing this too :/

joeykrug · 3 months ago

Also running into this on the UI side now too via the codex app. It says it thinks computer use is not approved via accessibility and automation but it is

figelwump · 3 months ago

I'm seeing this error as well when invoking Computer Use via the app server from a standalone client. Computer Use via Codex.app works fine on the same machine with the same prompts.

The bit of data I'll add to the conversation is that TCC is showing allowed indirect requests, so this might be a sender/session attribution problem (rather than a permission denial).

manikv12 · 2 months ago

<img width="3612" height="3104" alt="Image" src="https://github.com/user-attachments/assets/a33bb37c-961f-4025-8aca-3c3be052af01" />
Having issues on codex app as well.

net-snix · 2 months ago

Please fix

Alekstodo · 2 months ago

I’m seeing a related user-facing permission loop on the Codex macOS app side with Chronicle / dictation-like usage. The macOS prompt appears again even though the relevant Codex permissions have already been granted in System Settings.

Local details that may be useful:

  • macOS: 26.3 (25D125)
  • Codex app: 26.422.71525 / bundle version 2210
  • Codex app bundle id: com.openai.codex
  • bundled computer-use helper: computer-use@openai-bundled 1.0.758
  • helper bundle id: com.openai.sky.CUAService
  • launched helper path is the cache-side helper:
  • ~/.codex/plugins/cache/openai-bundled/computer-use/1.0.758/Codex Computer Use.app

Entitlement check:

  • /Applications/Codex.app includes com.apple.security.device.audio-input = true
  • Codex Computer Use.app / com.openai.sky.CUAService includes com.apple.security.automation.apple-events = true
  • Codex Computer Use.app / com.openai.sky.CUAService does not include com.apple.security.device.audio-input

That seems important because the current Chronicle docs say Chronicle requires Screen Recording and Accessibility, but “does not have access to your microphone or system audio.” So if this loop is being triggered through the helper/audio TCC path, the user-facing prompt is confusing: the user has already granted the visible Screen Recording / Accessibility permissions, but macOS still keeps surfacing Codex/System Access prompts.

I did not catch fresh TCC denial log lines in the last 2 hours, but the installed helper signature still matches the pattern described here, just on a newer helper version (1.0.758 vs 1.0.750).

manikv12 · 2 months ago

I'm not getting this error anymore after the latest release.

Jorjon · 1 month ago

Closing this as resolved for me.

I can no longer reproduce the original macOS CLI Computer Use failure (Apple event error -10000: Sender process is not authenticated). On my current install:

  • Codex CLI: codex-cli 0.135.0
  • Bundled Computer Use helper: openai-bundled/computer-use/1.0.799

I verified the Computer Use tool can list apps, inspect Finder UI, click, type, and send keyboard shortcuts. The issue was still reproducible on older helper builds around 1.0.750 / 1.0.758, so this appears to have been fixed by a later bundled Computer Use/helper update. I did not find a public linked PR or release note that identifies the exact fix.