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"
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 = trueis enabledplugins."computer-use@openai-bundled".enabled = true- stale local
computer-use@localoverrides 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?
- On macOS Apple Silicon, run
codexfrom the terminal. - Enable the bundled plugin in
~/.codex/config.toml:
[features]
apps = true
[plugins."computer-use@openai-bundled"]
enabled = true
- Install/launch the bundled helper once so
com.openai.sky.CUAServiceis registered. - Grant Accessibility and Screen Recording permissions to
Codex Computer Use. - Start a fresh Codex CLI session.
- Ask Codex to use Computer Use, for example:
use computer use to list apps - Observe failure:
- tool returns
Apple event error -10000: Sender process is not authenticated
- Check macOS unified logs / TCC logs around the failing call and observe a microphone/audio TCC denial for
com.openai.sky.CUAServicebecausecom.apple.security.device.audio-inputis 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/codexappears to contain plugin discovery/plumbing forcomputer-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.
11 Comments
Same issue
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-uselist_apps->Apple event error -10000: Sender process is not authenticatedWhat I verified locally:
computer-use@openai-bundled1.0.750com.openai.sky.CUAServicealready has system TCC grants for:kTCCServiceAccessibilitykTCCServiceScreenCaptureGhosttyandTerminal.appkTCCServiceAppleEvents | com.mitchellh.ghostty | com.openai.sky.CUAService | auth=2kTCCServiceAppleEvents | com.apple.Terminal | com.openai.sky.CUAService | auth=2Even after accepting those prompts,
list_appsstill returns the sameApple event error -10000.Most relevant
tccdline 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 entitlementI also saw the earlier AppleEvents attribution failure when
Codex.appwas 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
-10000surface error masking multiple underlying macOS permission/attribution failures, not just a missing user grant.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:
After adding the cache-side "Codex Computer Use.app" in System Settings and re-testing, a simple:
still fails with:
So in my case this is not resolved just by granting permissions to the actual helper app Codex is using.
seeing this too :/
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
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).
<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.
Please fix
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:
26.3 (25D125)26.422.71525/ bundle version2210com.openai.codexcomputer-use@openai-bundled1.0.758com.openai.sky.CUAService~/.codex/plugins/cache/openai-bundled/computer-use/1.0.758/Codex Computer Use.appEntitlement check:
/Applications/Codex.appincludescom.apple.security.device.audio-input = trueCodex Computer Use.app/com.openai.sky.CUAServiceincludescom.apple.security.automation.apple-events = trueCodex Computer Use.app/com.openai.sky.CUAServicedoes not includecom.apple.security.device.audio-inputThat 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.758vs1.0.750).I'm not getting this error anymore after the latest release.
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 0.135.0openai-bundled/computer-use/1.0.799I 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.