computer-use MCP: concurrent CLI sessions deadlock the shared screen-capture stream

computer-use MCP: concurrent CLI sessions deadlock the shared screen-capture stream

Summary

The bundled computer-use MCP server (in-process, serverVersion 0.1.3) is started per CLI
session. When two or more Claude Code sessions run concurrently (e.g. separate iTerm2 tabs in the
same project), they contend for the single macOS ScreenCaptureKit capture stream. The contention
wedges screen capture for the whole host-app (iTerm2) process tree:

• request_access / open_application return "Computer use is in use by another Claude session (<sessionId>)".
• screenshot returns Screenshot capture returned nil (permission missing or SCContentFilter failure) — even though Screen Recording permission is granted and fine.

It does not self-recover while the contending session is alive.

Environment

• Claude Code CLI (computer-use in-process MCP server, version 0.1.3)
• macOS (Apple Silicon), host terminal iTerm2, multiple tabs/sessions in the same project dir
• Screen Recording (TCC) granted to iTerm2

Steps to reproduce

1. In iTerm2 tab A, start a Claude Code session and use computer-use (request_access + screenshot). Works.
2. In iTerm2 tab B (new session, same project), start Claude Code and use computer-use there.
3. Tab B grabs the capture stream; tab A now fails: screenshot → nil (SCContentFilter failure), and request_access reports the resource is held by tab B's session id.
4. Neither session can capture until the contending session is terminated.

Expected

Concurrent sessions either (a) safely share/serialize the capture stream, or (b) fail with a clear,
self-clearing "another session holds computer use" error that releases as soon as that session ends —
without wedging capture for all sessions.

Actual

Capture is wedged for the host-app process tree. Recovery requires terminating the contending
session (see below). Users have previously believed a full iTerm2 restart was required.

Diagnosis (from the MCP logs)

Logs at ~/Library/Caches/claude-cli-nodejs/<project>/mcp-logs-computer-use/<ts>.jsonl show the
server is in-process and per-session:

{"debug":"In-process Computer Use MCP server started","sessionId":"e3b84f0d-…"}
{"debug":"Connection established with capabilities: …\"serverVersion\":{\"name\":\"computer-use\",\"version\":\"0.1.3\"}"}

Each session launch writes a log file with a distinct sessionId (confirmed across several
files: e3b84f0d…, d59c8c66…, 0e8cd96b…, 695cdcd5…). The newest-started session owns the
single SCStream; the others' SCContentFilter creation returns nil. The "in use by another session"
guard is process-local bookkeeping, but the underlying wedge is the shared ScreenCaptureKit stream
scoped to the iTerm2 responsible process.

There is no on-disk lock file — searched the CLI cache, /tmp, and /var/folders for a
computer-use lock or any file recording the holder session id; only normal session transcripts
contain it. So there's nothing to manually rm to recover.

Recovery / workaround (verified)

• Terminate the contending session (Ctrl-C / /exit in the other tab). The surviving session

then regains capture on its next screenshot — no iTerm2 restart needed. (Verified live:
closing the second tab immediately restored the first session's screenshots.)

• A full iTerm2 restart also works but is unnecessary if you can identify and close the contending

session.

Suggested fix direction

• Arbitrate the shared ScreenCaptureKit stream across concurrent in-process servers (single owner

with clean handoff), or

• On contention, fail fast with a non-wedging error and release the SCStream immediately when a

session disconnects, so the survivor can re-acquire without manual intervention.