Codex Desktop MCP app widgets deny microphone access despite declared permission

Codex App version

26.715.52143

Subscription

ChatGPT Pro

Platform

Darwin 25.5.0 arm64 arm

What issue are you seeing?

An MCP Apps SDK widget cannot access the microphone inside a Codex Desktop task, even though:

• The widget resource declares ui.permissions: { microphone: {} }.
• The document is a secure context.
• navigator.mediaDevices.getUserMedia is available.
• The iframe Permissions Policy reports that the microphone feature is allowed.
• ChatGPT/Codex has already been granted microphone access in macOS System Settings.

The permission query still reports denied, and getUserMedia({ audio: true }) throws:

NotAllowedError: Permission denied

Diagnostic output from the Codex Desktop widget:

{
  "secure_context": true,
  "embedded_iframe": true,
  "media_devices_available": true,
  "get_user_media_available": true,
  "permission_api_state": "denied",
  "permission_policy_allows_microphone": true,
  "error": {
    "name": "NotAllowedError",
    "message": "Permission denied"
  }
}

The same remote MCP connector and widget work correctly in ChatGPT on Chrome. There, the permission state is granted, getUserMedia succeeds, and the voice experiment runs normally.

Steps to reproduce

1. Register an MCP Apps SDK widget whose resource metadata contains:

ui: {
  permissions: {
    microphone: {}
  }
}

1. Add a user-initiated button that calls:

await navigator.mediaDevices.getUserMedia({ audio: true });

1. Open the widget inside a Codex Desktop task.
2. Click the button.
3. Observe NotAllowedError: Permission denied.
4. Open the same connected MCP widget in ChatGPT on Chrome.
5. Observe that microphone permission is granted and audio capture works.

Expected behavior

If microphone access declared through ui.permissions is supported in Codex Desktop, the host should allow the normal permission flow after a user gesture and macOS approval.

If microphone access is intentionally unsupported for MCP app widgets in Codex Desktop, the limitation should be documented or exposed through a clear capability signal rather than reporting that the iframe policy allows it and then rejecting it at the host session layer.

Questions

1. Is the blanket denial of microphone or media permissions inside Codex Desktop MCP app sandboxes intentional?
2. If intentional, what security rationale requires it when the same widget permission is supported on ChatGPT web?
3. Is there a planned path for Codex Desktop to honor ui.permissions.microphone for user-initiated audio capture?
4. Is there a recommended supported alternative for an MCP widget that needs realtime voice input while preserving the active Codex task context?

Additional information

Inspection of the locally installed desktop bundle suggests that the Electron session used for MCP app sandbox webviews installs permission request and permission check handlers that reject all permissions. This appears consistent with the observed behavior, although it is unclear whether this is an intentional product policy or an incomplete allowlist.

Related feature requests include #33221 and #33548, but this report is narrower: it concerns microphone access from an Apps SDK/MCP widget that already works on ChatGPT web, not a request for native Codex voice mode or composer dictation.