[macOS x86_64] Microphone prompt blocked by TCC: CS_PLATFORM_BINARY set but not AppleSigned

Codex App version

26.721.41059 (build 5848)

Bundle identifier: com.openai.codex

Subscription

Unknown (the failure occurs in the local macOS TCC policy before any account- or model-level voice request).

Platform

Darwin 25.5.0 x86_64 i386
macOS 26.5 (25F71)
13th Gen Intel(R) Core(TM) i7-13700K

This is a custom x86_64 macOS environment on 13th-generation Intel hardware, not an Apple-manufactured Intel Mac. I am reporting it because the Codex App currently provides an x86_64 build and the failure exposes a specific code-signing/TCC classification mismatch rather than a generic unsupported-device error.

What issue are you seeing?

Starting composer dictation or Voice fails with:

Voice chat couldn't start
Permission denied

macOS never displays the microphone authorization prompt. Codex/ChatGPT does not appear under System Settings > Privacy & Security > Microphone.

The app log records the attempted input:

2026-07-25T02:10:32.492Z error [electron-message-handler] [Composer] unable to start dictation error={}

At the same instant, the macOS tccd unified log shows that the request reaches TCC but the prompt is denied by policy:

service=kTCCServiceMicrophone, preflight=no
CS_PLATFORM_BINARY set but not AppleSigned; prompt policy is Deny.
Policy disallows prompt for Sub:{com.openai.codex} ... access to kTCCServiceMicrophone denied
AUTHREQ_RESULT: authValue=0, authReason=5

No microphone decision is persisted:

sqlite3 "$HOME/Library/Application Support/com.apple.TCC/TCC.db" \
  "select count(*) from access where service='kTCCServiceMicrophone' and client='com.openai.codex';"
# 0

This means tccutil reset cannot help: TCC rejects the request before showing or recording a user decision.

What steps can reproduce the bug?

1. Install the official Codex/ChatGPT app in /Applications/ChatGPT.app.
2. Quit the app.
3. Run:

``sh
tccutil reset Microphone com.openai.codex
``

1. Reopen the app.
2. Click the composer microphone/dictation control or start Voice.
3. Observe Permission denied.
4. Observe that no macOS microphone prompt appears and no Codex/ChatGPT entry is added to the Microphone privacy list.
5. Inspect tccd:

``sh
/usr/bin/log show --style compact --info --debug \
--start '2026-07-24 19:10:30' \
--end '2026-07-24 19:10:35' \
--predicate 'process == "tccd"'
``

1. Observe CS_PLATFORM_BINARY set but not AppleSigned; prompt policy is Deny.

The denial repeats deterministically for each microphone attempt.

What is the expected behavior?

After a user gesture, macOS should display the microphone authorization prompt. Once allowed, composer dictation and Voice should be able to capture audio.

If this x86_64 environment is intentionally unsupported, the app should surface a clear compatibility error instead of presenting a generic Permission denied message and repeatedly issuing a TCC request that macOS will never prompt for.

Additional information

The app's normal static signature verification succeeds:

/Applications/ChatGPT.app: valid on disk
/Applications/ChatGPT.app: satisfies its Designated Requirement

The main app also contains the expected entitlement:

com.apple.application-identifier = 2DC432GLL2.com.openai.codex
com.apple.developer.team-identifier = 2DC432GLL2
com.apple.security.device.audio-input = true

Other checks performed:

• A valid microphone input device is present and selected.
• No MDM/DEP restriction is active.
• Resetting the TCC microphone decision and restarting the app does not change the result.
• The user TCC database contains no microphone row for com.openai.codex.
• The public Codex issue tracker was searched for the exact TCC error and related microphone failures. #17158 concerns feature-gate rollout and #34304 concerns MCP widget iframe permissions; neither matches this native app TCC prompt-policy denial.

The notable mismatch is that codesign --verify --deep --strict succeeds and the audio-input entitlement is present, while TCC classifies the responsible process as CS_PLATFORM_BINARY but not Apple-signed and therefore refuses to prompt.

Could you please check the code-signing flags and designated requirements of the x86_64 Codex App bundle and its Electron helper processes, or clarify whether this hardware/OS combination is unsupported?