[macOS] Computer Use captures Stage Manager thumbnail, poisons ScreenCaptureKit stream (-3811/-3812)

Open 💬 1 comment Opened Aug 13, 2026 by AryanRG

Summary

With macOS Stage Manager enabled, Codex Computer Use can select an inactive app's Stage Manager thumbnail instead of its real window. The thumbnail has off-screen/negative window coordinates, so ScreenCaptureKit fails its display lookup. That failed capture can then poison the shared capture service: subsequent captures of unrelated, valid on-screen apps also return SCStreamErrorDomain errors until the service is restarted.

Disabling Stage Manager resolves the issue.

Environment

  • macOS: 27.0 (26A5378n), Apple Silicon / arm64
  • ChatGPT/Codex Desktop: 26.803.61601 (build 6396)
  • Computer Use plugin/runtime: 1.0.1000633
  • Displays: one active built-in display
  • Stage Manager: enabled when reproducing
  • Screen Recording and Accessibility permissions: enabled for ChatGPT and Codex Computer Use
  • Feedback session: 019ffaa1-04c8-7f82-a598-5ffa29e6aa2d

Actual behavior

Computer Use initially returned a screenshot for TextEdit, but it was a distorted Stage Manager thumbnail rather than the full application window.

Unified ScreenCaptureKit logs showed the selected thumbnail outside the active display:

SCContentFilter setContentsAndStreamTypeMacOS:
failed display lookup for windowBounds=<private> cgError=0 found=0

contentRect=[x=-271.000000 y=701.000000 width=154.000000 height=122.000000]

Computer Use then returned:

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

and later:

Computer Use server error -10005:
Error Domain=com.apple.ScreenCaptureKit.SCStreamErrorDomain Code=-3812
"Failed due to an invalid parameter"

After the TextEdit failure, a previously working Calculator capture also failed with -3812, showing that one invalid Stage Manager target can leave the shared capture service in a bad state.

Restarting only SkyComputerUseService did not reliably recover while Stage Manager remained enabled; the next target capture could immediately fail again.

Reproduction

  1. Enable macOS Stage Manager and leave its recent-app strip visible.
  2. Open TextEdit and Calculator.
  3. Switch away from TextEdit so it appears in the Stage Manager strip.
  4. Ask Codex Computer Use to inspect TextEdit with get_app_state.
  5. Observe either:
  • a distorted/perspective Stage Manager thumbnail screenshot, or
  • SCStreamErrorDomain -3811 / -3812.
  1. Ask Computer Use to inspect Calculator.
  2. Observe that Calculator can now fail with the same capture error even though its window geometry is valid.

Expected behavior

  • Computer Use should activate and capture the real application window, not a Stage Manager thumbnail.
  • Off-screen/thumbnail windows should be rejected before constructing the ScreenCaptureKit content filter.
  • A failed window capture should not corrupt later captures for other applications.
  • On -3811 or -3812, the service should discard the invalid filter/stream state and recover automatically.

Workaround and validation

  1. Disable Stage Manager in System Settings > Desktop & Dock.
  2. Restart the dedicated Computer Use capture service.
  3. Re-run captures.

After disabling Stage Manager:

  • TextEdit changed from the distorted thumbnail to a normal full-window screenshot.
  • Six alternating get_app_state calls across TextEdit and Calculator all succeeded.
  • No new failed display lookup or SCStreamErrorDomain messages appeared in the verification window.

Suggested guards

  • Exclude Stage Manager strip thumbnails from candidate target windows.
  • Validate that a target window intersects an active SCDisplay before creating SCContentFilter.
  • Prefer an actual on-screen standard window over off-screen/transformed representations of the same app.
  • Recreate SCShareableContent, SCContentFilter, and stream state after -3811 / -3812.
  • Add a regression test where an app is in the Stage Manager recent-app strip, followed by a capture of a separate on-screen app.

Related issues

  • #30846 reports the same generic -3811 wrapper, but with a different suspected trigger (audio entitlement/helper lifecycle). This report includes a deterministic Stage Manager/off-screen-window trigger and the additional -3812 poisoned-stream behavior.
  • #37115 covers a separate Computer Use PiP/Stage Manager focus-stealing interaction.

View original on GitHub ↗

1 Comment

noahhhi · 5 days ago

Additional macOS 27 reproduction showing failed display lookup is not limited to Stage Manager.

Environment:

  • macOS 27.0 beta, build 26A5416b, Apple silicon
  • ChatGPT/Codex Desktop 26.818.41509, build 6962
  • Computer Use helper 26.819.1000816
  • Stage Manager was not the triggering condition
  • ScreenCapture and Accessibility are allowed for com.openai.sky.CUAService (system TCC auth_value=2)

Same helper/session comparison:

  • get_app_state(Finder) succeeded with screenshot and AX data.
  • get_app_state(Calculator), whose window was not mappable to the current active display/Space, failed with SCStreamErrorDomain -3811.
  • Targeted unified logging at the failure recorded:

ScreenCaptureKit: failed display lookup for windowBounds=<private> cgError=0 found=0
replayd: Failed to start stream due to audio/video capture failure

Because Finder succeeded immediately in the same process and TCC state was allowed, this is not a global Screen Recording permission failure. The target-window/display association appears stale or invalid across Spaces/background window state even without Stage Manager.

Suggested guard: validate target-window intersection with an active SCDisplay, refresh SCShareableContent before building the filter, reject stale/off-Space candidates, and retry once with a new stream after -3811.

No private window contents or full system logs are included.