computer-use MCP: captureScreenWithExclusion leaks continuation on macOS 26.5 (still repros in 2.1.114)

Resolved 💬 3 comments Opened Apr 20, 2026 by cgdmrt Closed Apr 23, 2026

Summary

mcp__computer-use__screenshot hangs and emits a Swift continuation leak, leaving screenshot tasks suspended forever:

SWIFT TASK CONTINUATION MISUSE: captureScreenWithExclusion(displayId:width:height:allowedBundleIds:jpegQuality:) leaked its continuation without resuming it. This may cause tasks waiting on it to remain suspended forever.

Once it fires, subsequent screenshot calls in the same process stay stuck until the MCP server is restarted.

Environment

  • Claude Code CLI 2.1.114
  • macOS 26.5 (Tahoe), build 25F5053d / Darwin 25.5.0
  • Shell: zsh
  • Screen Recording permission granted to Terminal
  • computer-use enabled via /plugin

Context / prior issues

This is the same class of bug previously reported and closed without a shipped fix:

  • #41116 — root cause investigation pointed at (a) SCContentFilter(including:) returning error -3811 when the allowlisted app has no visible windows, and (b) Bun runtime not providing a RunLoop for Swift async callbacks. Closed by OP after an iTerm restart masked the symptom.
  • #45414 — detailed repro with a proposed safe-resume patch. Auto-closed by bot as "doesn't appear to be about Claude Code" (it is — the leak is inside the bundled computer_use.node / computer-use-swift.node).
  • #41178 — iOS Simulator variant, auto-closed as duplicate of #41116.

Filing fresh because all three are locked and the bug still reproduces on the current Claude Code build.

Why the prior closures were premature

The underlying continuation leak is a real code defect regardless of which trigger path lands on it. Even if the immediate trigger is a permission/filter edge case, the withCheckedContinuation usage must resume in every path — otherwise any future trigger (permission race, display sleep, -3811, empty filter) produces the same hang. The safe-resume pattern in #45414 is the correct fix.

Suggested fixes (from prior threads)

  1. Wrap captureScreenWithExclusion's continuation in a guarded safeResume so every code path (success, error, guard, nil-display) resumes exactly once.
  2. Handle SCStream error -3811 explicitly when the including: filter resolves to no visible windows — fall back to excludingWindows: or return a clear error instead of leaving the completion handler silent.
  3. If the Bun-runtime RunLoop hypothesis from #41116 is correct, dispatch Swift async completions onto an explicitly-managed DispatchQueue rather than relying on the host's RunLoop.

Workarounds users are currently relying on

  • Full terminal restart (not just MCP reconnect) so Screen Recording is re-evaluated.
  • Ensure an allowlisted app has a visible window on screen before calling screenshot.
  • Use Claude Desktop (Electron) for computer-use instead of the CLI (Bun).
  • For iOS Simulator: xcrun simctl io <device> screenshot (loses click-coordinate mapping).

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗