›_ Claude Code Issues
Claude Code Issues / #41116

[BUG] computer-use screenshot fails on macOS Tahoe 26.x — Swift continuation leak

Status Fixed / completed
Reported on v2.1.87
Maintainer reply None cached
Activity 5 comments · opened Mar 30, 2026 · closed Mar 30, 2026

Environment

  • macOS Tahoe 26.3 (Build 25D5112c)
  • Claude Code 2.1.87
  • Max plan, interactive session
  • Computer use enabled via /plugin

Bug

screenshot tool fails every time with:

  • "Screenshot capture returned nil (permission missing or SCContentFilter failure)"
  • Or: timeout after 30s
  • Terminal shows: SWIFT TASK CONTINUATION MISUSE: captureScreenWithExclusion(displayId:width:height:allowedBundleIds:jpegQuality:) leaked its continuation without resuming it

Permissions confirmed

  • Screen & System Audio Recording: Terminal ✅, node ✅, Claude ✅
  • Accessibility: granted

Proof: ScreenCaptureKit works on Tahoe

Compiled and ran this Swift test — works perfectly, captures 1680x1050:

import ScreenCaptureKit, AppKit
@main struct App {
    static func main() async {
        let content = try! await SCShareableContent.excludingDesktopWindows(false, onScreenWindowsOnly: true)
        let display = content.displays.first!
        let filter = SCContentFilter(display: display, excludingWindows: [])
        let config = SCStreamConfiguration()
        config.width = display.width; config.height = display.height
        let image = try! await SCScreenshotManager.captureImage(contentFilter: filter, configuration: config)
        print("✅ Works! \(image.width)x\(image.height)")
    }
}

Conclusion

The ScreenCaptureKit API works fine on Tahoe. The bug is in computer_use.node — likely the withCheckedContinuation callback not being called on Tahoe, causing the continuation leak.

Other computer-use tools (request_access, open_application) work correctly. Only screenshot is affected.

View original on GitHub ↗

5 Comments

dsur91 · 6 months ago

Additional note: discoverability

The official documentation says to enable computer-use via /mcp, but on our setup computer-use did NOT appear in the /mcp server list.

We found it in /plugin (built-in plugins) where it was listed as disabled. After enabling it there, the computer-use tools loaded correctly and request_access, open_application etc. all work. Only screenshot fails due to the continuation leak described above.

This might be worth noting in the docs — users looking in /mcp won't find it if it's registered as a plugin rather than an MCP server.

dsur91 · 6 months ago

Root cause found!

The issue is NOT a general ScreenCaptureKit incompatibility with Tahoe. It's a specific edge case with the including: filter.

Findings:

  1. SCContentFilter(display:, excludingWindows: []) (no app filter) → ✅ Works on Tahoe
  2. SCContentFilter(display:, including: [iTerm2], exceptingWindows: []) (visible app) → ✅ Works on Tahoe
  3. SCContentFilter(display:, including: [Finder], exceptingWindows: []) (no visible windows) → ❌ Error -3811 "Failed to start stream due to audio/video capture failure"

What happens in computer-use:

  • request_access grants Finder
  • Other apps get hidden
  • screenshot tries to capture with including: [Finder]
  • Finder has no visible windows on screen → SCContentFilter is effectively empty → capture fails/hangs with continuation leak

The fix: When using the including: filter on Tahoe, ensure at least one included app has a visible window, or fall back to excludingWindows: filter. The continuation should also handle the -3811 error gracefully instead of leaking.

Test code used: Same Swift ScreenCaptureKit test as above, but with SCContentFilter(display:, including: apps, exceptingWindows: []) — works for visible apps, fails for apps without visible windows.

dsur91 · 6 months ago

Updated diagnosis — root cause confirmed via Desktop comparison

Tested the same computer-use screenshot in Desktop app (Electron) — works perfectly. Compared with CLI (Bun runtime) — fails.

Key differences found:

| | Desktop (works) | CLI (fails) |
|---|---|---|
| Runtime | Electron | Bun |
| Module | computer_use.node (universal binary, 925KB) | computer-use-swift.node (embedded via bunfs) |
| Process | Claude.app with bundle ID com.anthropic.claudedesktop | Plain executable, no bundle |
| RunLoop | Electron provides proper RunLoop | Bun may not provide RunLoop for Swift async/await |
| Screen Recording | Granted to Claude.app bundle | Granted to Terminal |

Root cause:

Bun runtime does not provide a proper RunLoop for Swift async/await callbacks. The computer-use-swift.node module uses ScreenCaptureKit which relies on Swift concurrency (withCheckedContinuation). When the callback from SCScreenshotManager.captureImage fires, it needs a RunLoop to dispatch back to — Bun doesn't provide one, so the continuation is never resumed → leak → timeout.

This explains why:

  • Our standalone Swift test works (compiled binary has its own RunLoop)
  • Desktop works (Electron provides RunLoop)
  • CLI fails (Bun doesn't provide RunLoop for Swift callbacks)

Suggested fix:

The CLI's computer-use-swift.node needs to create its own CFRunLoop dispatch or use DispatchQueue.main explicitly rather than relying on the host runtime's RunLoop.

dsur91 · 6 months ago

Closing — issue resolved. The screenshot failure was caused by Screen Recording permission not being fully picked up by iTerm until a full restart. After restarting iTerm, native computer-use screenshots work correctly on macOS Tahoe 26.3. Apologies for the noise!

github-actions[bot] · 6 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Same class of failure, ranked by community engagement — this issue is one of many, so it may not appear in the visible list: Windows & WSL problems

Browse all Claude Code issue topics →