2026 Cloud Mac concurrent SSH and Screen Sharing lock runbook: unfreeze MacLogin Apple Silicon when PTY automation collides with remote GUI

Platform engineers who mix headless ssh sessions with interactive Screen Sharing on the same macOS user often see “random” hangs that are neither network outages nor CPU saturation. The practical conclusion for April 2026: console-session contention—WindowServer, loginwindow, and PTY-bound automation fighting for the same GUI context—produces symptoms that look like flaky VNC but are actually local locks. This runbook gives you a freeze symptom matrix, nine ordered remediation steps, a five-column port and daemon collision table, unified logging predicates you can paste into a ticket, and FAQ tuned for MacLogin leases in Hong Kong, Tokyo, Seoul, Singapore, and the United States.

Pair it with shared SSH session governance, VNC clipboard and screen recording policy, and SSH key rotation plus 2FA. When the incident concludes with a lease return, follow enterprise offboarding sanitization. Operational anchors: pricing, help, VNC.

When concurrent remote sessions stall (and why blame the wrong layer)

Three pain patterns dominate April 2026 incident bridges on leased minis:

• CI over SSH launches osascript or xcodebuild while a human watches the same desktop over Screen Sharing—both assume Aqua is responsive.
• Security software prompts a TCC dialog that only renders on the hardware console, invisible to the Screen Sharing viewer, so automation blocks for 27–40 minutes until someone attaches physically or kills the job.
• Multiple Screen Sharing viewers attach after an SSH port forward to 5900; each extra viewer multiplies framebuffer diffs and can push WindowServer past 85% GPU time even when CPU looks idle.

Freeze symptom matrix (pick the column before you reboot)

Observable signal	SSH-only hypothesis	Screen Sharing hypothesis	First action	Evidence to collect
Cursor moves but clicks do nothing	Stuck sudo password helper	WindowServer wedged	Pause CI; disconnect second viewer	sample WindowServer 10s
SSH session accepts input but GUI frozen	PTY still healthy	GUI lock on console user	Switch to secondary admin account test	loginwindow heartbeat logs
Both channels freeze within 5s	Kernel I/O stall or APFS snapshot	Same root cause	Check diskutil apfs listSnapshots	storage pressure graph
Screen Sharing drops every 11 minutes	Idle TCP timeout upstream	ARD keepalive mismatch	Enable SSH tunnel keepalive 60s	TCP capture on client

Lock mechanisms: console, ARD agent, and SSH PTY interplay

macOS ties many automation primitives to the console user session. Screen Sharing streams that session. SSH can either stay headless (no GUI) or invoke tools that implicitly require GUI context. When both hit together, you see priority inversion: loginwindow still services authentication, but WindowServer cannot composite new frames because a tool holds a CGS lock.

On MacLogin hosts, ARD/Screen Sharing typically listens on 5900 with optional dynamic ports 5901–5903 for observe-only viewers. SSH port forwards often hard-code 5900, which collides with native listeners if engineers duplicate forwards after sleep/wake cycles on their laptops.

Nine-step remediation runbook (ordered; do not skip)

1. Tag the blast radius in your ticket: lease ID, metro (HK/JP/KR/SG/US), console username, count of Screen Sharing clients, count of interactive SSH sessions.
2. Pause CI that runs UI tests for at least 6 minutes—long enough for stuck osascript helpers to exit.
3. Disconnect all but one Screen Sharing viewer; wait 90 seconds before judging responsiveness.
4. Validate listeners with netstat -an | grep 590 and remove duplicate SSH forwards.
5. Rotate to a secondary macOS user if your governance allows split build vs operator accounts per shared build account guide.
6. Capture unified logs for 300 seconds using predicates in the next section; attach gzip to the ticket.
7. Apply display sleep reset remotely via pmset displaysleepnow followed by wake-on-network if enabled—clears some stuck compositor states without reboot.
8. Reboot only if step 7 fails twice; schedule reboots outside trading hours for JP finance tenants.
9. Post-incident add a roster note documenting which automation must never overlap Screen Sharing again.

Port and daemon collision matrix

TCP port	Typical owner	Conflict signature	Mitigation
22	OpenSSH	MaxStartups throttling bursts	Raise staging MaxStartups carefully; prefer jump host
5900	Screen Sharing	Double SSH -L forwards	Use unique local ports per engineer
3283	ARD agent (legacy)	Mixed ARD + Screen Sharing policies	Disable unused ARD features in Server policy
dynamic	USB session tools	HID emulation for tests	Run HID suites on dedicated leases

Unified log predicates and evidence pack

Collect three bundles so MacLogin support can replay the incident without guessing:

• WindowServer focus: log show --last 20m --predicate 'process == "WindowServer"'
• Screen Sharing auth: log show --last 20m --predicate 'process == "screensharingd"'
• SSH session tuple: export SSH_CONNECTION from each stuck session and paste into the ticket body.

Retention target: keep compressed logs for 35 days on shared buckets so JP and US regulators can review the same tarball without re-pulling from the lease.

FAQ

Is it safe to run sudo pkill ScreenSharing over SSH? Only after idle viewers disconnect; otherwise you may strand an engineer mid-filevault unlock.

Should we ban Screen Sharing entirely? No—many macOS prompts require GUI. Instead schedule Screen Sharing windows and document them beside CI calendars.

Does MacLogin throttle Screen Sharing bandwidth? Metro-specific network shaping is documented in pricing; expect higher jitter on saturated cross-region paths.

Why Mac mini M4 helps concurrent remote workflows

Apple Silicon M4 pairs a wider GPU framebuffer path with efficient media engines, which keeps Screen Sharing responsive when engineers tail large Xcode logs over SSH in parallel. Unified memory reduces swap thrash compared with small x86 VMs that split GPU and CPU RAM pools. MacLogin’s HK, JP, KR, SG, and US fleet lets you park GUI-heavy leases next to the teams that need them while CI stays on headless profiles—lowering the odds that a Tokyo trader and a Singapore bot share the same console context by accident.

Renting keeps experimentation reversible: if concurrency incidents exceed 3 per month even after this runbook, split workloads across two leases from pricing instead of overloading one mini with both Aqua automation and human Screen Sharing.