computer-use MCP: captureScreenWithExclusion leaks continuation on macOS 26.5 (still repros in 2.1.114)
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)
- Wrap
captureScreenWithExclusion's continuation in a guardedsafeResumeso every code path (success, error, guard, nil-display) resumes exactly once. - Handle SCStream error -3811 explicitly when the
including:filter resolves to no visible windows — fall back toexcludingWindows:or return a clear error instead of leaving the completion handler silent. - If the Bun-runtime RunLoop hypothesis from #41116 is correct, dispatch Swift async completions onto an explicitly-managed
DispatchQueuerather 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).
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗