›_ Codex Issues
Codex Issues / #30846

Computer Use fails to start ScreenCaptureKit stream with SCStreamErrorDomain -3811

Open 💬 0 comments Opened Jul 1, 2026 by johnsilvavlogs

Summary

Computer Use failed to start a macOS ScreenCaptureKit stream and surfaced only a generic Computer Use server error:

Computer Use server error -10005: Error Domain=com.apple.ScreenCaptureKit.SCStreamErrorDomain Code=-3811 "Failed to start stream due to audio/video capture failure" UserInfo={NSLocalizedDescription=Failed to start stream due to audio/video capture failure}

Local diagnosis suggests this is not a simple Screen Recording permission denial. com.openai.codex and com.openai.sky.CUAService are allowed for Screen Capture, and a fresh Computer Use thread can capture Finder after stale helpers are cleared. The stronger evidence points to the Computer Use service attempting an audio/microphone path without the hardened-runtime audio-input entitlement, plus weak helper cleanup/rebind behavior.

Environment

  • Codex Desktop: 26.623.81905, build 4598
  • Codex app bundle ID: com.openai.codex
  • App-bundled CLI: codex-cli 0.142.5
  • Global CLI: codex-cli 0.142.1
  • Computer Use service: com.openai.sky.CUAService, version 1.0, build 857
  • Computer Use client: com.openai.sky.CUAService.cli, version 1.0, build 857
  • macOS: 26.5.1, build 25F80
  • Kernel/platform: Darwin 25.5.0 arm64 arm

What happened

The visible user-facing failure was:

Computer Use server error -10005: Error Domain=com.apple.ScreenCaptureKit.SCStreamErrorDomain Code=-3811 "Failed to start stream due to audio/video capture failure" UserInfo={NSLocalizedDescription=Failed to start stream due to audio/video capture failure}

At the time of diagnosis, there was abnormal Computer Use helper fan-out:

  • 27 SkyComputerUseClient / SkyComputerUseService processes matched before cleanup.
  • Several client/helper groups were older than 5-11 hours.
  • The standalone SkyComputerUseService was consuming roughly 8-12% CPU.
  • Codex Desktop logs also showed earlier MCP request timeouts such as app/list and mcpServerStatus/list.

I terminated only the SkyComputerUseClient and SkyComputerUseService processes, preserving Codex Desktop, app-server, thread state, and other MCP servers. A fresh SkyComputerUseService then launched.

Key local evidence

TCC state:

  • System TCC DB shows auth_value=2 for com.openai.codex on kTCCServiceScreenCapture.
  • System TCC DB shows auth_value=2 for com.openai.sky.CUAService on kTCCServiceScreenCapture.
  • System TCC DB shows auth_value=2 for com.openai.codex on Accessibility.
  • User TCC DB has Microphone permission for com.openai.codex, but no Microphone/AudioCapture grant for com.openai.sky.CUAService.

Entitlements:

  • Main Codex.app has com.apple.security.device.audio-input, camera, and AppleEvents entitlements.
  • SkyComputerUseService and SkyComputerUseClient appear to have only app-group/keychain entitlements.

Unified logs around the failure window showed this pattern:

  • SkyComputerUseService created an SCStream.
  • ScreenCapture TCC requests returned allowed.
  • tccd logged that kTCCServiceMicrophone requires com.apple.security.device.audio-input, but that entitlement is missing for SkyComputerUseService.
  • CoreAudio then logged a proxy failure (0x6E6F7065 / 1852797029) before the stream was torn down.

The exact SCStreamErrorDomain -3811 line did not reappear verbatim in unified logs during this diagnosis; it was visible in the Codex transcript/UI screenshot. The TCC/CoreAudio/SCK cluster is the likely underlying cause for the reported "audio/video capture failure".

Post-cleanup verification

After clearing stale SkyComputerUse* helpers:

  • In a fresh Codex thread, mcp__computer_use.list_apps succeeded.
  • In that same fresh thread, mcp__computer_use.get_app_state({"app":"Finder"}) succeeded and returned screenshot/accessibility data.
  • mcp__computer_use.get_app_state({"app":"Codex"}) failed due to the tool's built-in safety boundary around operating Codex itself, not the original ScreenCaptureKit error.
  • In the original manager thread, the previously loaded Computer Use MCP handle continued to return Transport closed until the thread/tool transport is rebound. So cleanup restores fresh-thread Computer Use, but the current thread's stale transport does not self-heal.

Expected behavior

Computer Use should either:

  • start capture and return screenshot/accessibility state; or
  • fail with a typed, actionable diagnostic that distinguishes missing TCC permission, missing service entitlement, stale helper state, target-window/display invalidation, lock-state incompatibility, or native ScreenCaptureKit/CoreAudio failure.

It should not collapse SCStreamErrorDomain -3811 into only Computer Use server error -10005, and stale helper cleanup should not leave the already loaded MCP transport permanently closed inside the current thread.

Suggested fixes / guards

  • Avoid requesting microphone/audio capture for screenshot-only or app-state Computer Use paths when audio is not required.
  • If audio is required, sign SkyComputerUseService with the needed hardened-runtime audio-input entitlement and make the required TCC path explicit.
  • Add a preflight that checks ScreenCapture, Accessibility, and audio entitlement/grant state before creating SCStream.
  • On SCStreamErrorDomain -3811, retry once with fresh SCShareableContent, SCContentFilter, and capture configuration after a short backoff, then return a typed diagnostic.
  • Add helper lifecycle cleanup so stale SkyComputerUseClient/SkyComputerUseService fan-out does not accumulate across threads.
  • If a helper/client is killed or crashes, make the Computer Use MCP transport rebind/restart automatically in the active thread rather than returning Transport closed.

Regression tests that would cover this

  • Normal unlocked macOS session: Computer Use get_app_state(Finder) returns screenshot/accessibility state with stable helper count.
  • Screenshot-only path: capture succeeds without requesting microphone/audio.
  • Missing audio entitlement/grant edge: returns a typed audio entitlement/TCC diagnostic rather than generic -10005.
  • Stale helper edge: after killing or crashing SkyComputerUseService/client, the next Computer Use call either restarts/rebinds cleanly or returns a typed stale-helper diagnostic.
  • Capture contention edge: another ScreenCaptureKit client active or replayd loaded should lead to bounded retry or typed contention/native-SCK error.

Related issues checked

No exact public duplicate found for SCStreamErrorDomain -3811 plus the full Computer Use -10005 wrapper.

Nearby but not exact:

View original on GitHub ↗