I'm sharing a recovery workaround for recurring Sidecar “The device timed out” failures. I have verified that this procedure restored connectivity on three separate occurrences: October 5, 6, and 12, 2026, using the same Mac and iPad.
Environment and symptoms
MacBook Air (M4), macOS 26.6.2.
iPad Pro 12.9-inch (3rd generation), iPadOS 26.6.2.
Sidecar used as an extended display over USB.
During the failures, the iPad was unlocked and paired/trusted, and the USB network interface remained active and reachable. New Sidecar connection attempts timed out after approximately 10 seconds with SidecarErrorDomain (-201).
Recovery procedure
Prerequisites: Xcode installed and selected for command-line tools, and an unlocked iPad connected to the Mac via USB. The iPad must trust the Mac and have Developer Mode enabled for this devicectl workflow.
Run these commands in Terminal on the Mac:
List devices and identify the affected iPad:
xcrun devicectl list devices
List processes on that iPad:
xcrun devicectl device info processes --device "<DEVICE_ID>"
Find the entry whose executable path is exactly /usr/libexec/SidecarRelay, and note its current PID.
Force-terminate that process on the iPad:
xcrun devicectl device process terminate \
--device "<DEVICE_ID>" \
--pid <PID> \
--kill
Replace the placeholders with your iPad's identifier and the PID just obtained. Target the iPad-side relay, and obtain a fresh PID whenever the issue recurs.
Reconnect the iPad from macOS System Settings → Displays → Add Display, or Control Center → Screen Mirroring.
Verified result and limitations
On all three occasions, terminating only the iPad's old SidecarRelay and reconnecting restored USB extended-display operation. Neither device needed a reboot, and no account sign-out or settings reset was required. A new iPad SidecarRelay process appeared on reconnection; the Mac-side relay remained running.
On the first occurrence, an ordinary termination attempt without --kill left the same iPad process alive; the force-termination step was necessary in that test.
This is a recovery workaround, not a confirmed permanent fix. The initiating trigger and internal failure mechanism remain unknown. Controlled tests of normal disconnection, short sleep with the cable connected, and disconnect → unplug → sleep → wake → reconnect did not reliably reproduce the persistent timeout. These results do not prove a deadlock or establish unplugging/sleep as the cause.
If you are investigating the underlying trigger, capture diagnostics while the failure is present, before terminating the relay.
A similar recovery approach is documented in Lontronix's “Kick SidecarRelay” gist.
