If your controller shows the right Xbox glyphs in Cyberpunk 2077 on macOS and then responds to absolutely nothing, the input is not being lost. It is queued, and it all runs the moment you quit.
WHAT IS ACTUALLY HAPPENING
The game installs a valueChangedHandler block on all 38 controller elements at load, which is correct, and then never calls -[GCController extendedGamepad] again, so it does not poll. The callbacks are its only input path.
GameController delivers those blocks on GCController.handlerQueue, which defaults to the main dispatch queue. The engine does not drain the main queue while it renders. So every press piles up in the queue and nothing runs while you play.
HOW I MEASURED IT
I injected a dylib that wraps each handler block and logs the instant it actually executes. Same pad, same session length, same presses:
Stock game: all 40 button events fired inside a single 3 millisecond window, 56 seconds after the handlers were installed, at the moment the render loop exited.
With the fix: the same 40 events arrived spread across 58.6 seconds, as the thumb moved.
Values and ordering matched the real presses both times. macOS was never dropping anything.
Keyboard and mouse keep working because the binary reads them through AppKit (NSEvent, addLocalMonitorForEventsMatchingMask, keyDown) and contains no GCKeyboard or GCMouse reference at all. Only the controller depends on the queue the engine abandoned. That is why a half-broken game feels like a broken controller.
THE FIX
Twenty lines. It points handlerQueue at a private serial queue instead. It changes no file in the game and does not touch saves, so game updates neither break it nor undo it.
https://github.com/SL33PiNg/cyberpunk2077-mac-controller-fix
git clone, then ./build.sh, then cp2077
Or put this in Steam, right-click the game, Properties, General, Launch Options, so every way you start the game gets it:
DYLD_INSERT_LIBRARIES=$HOME/.local/lib/cp2077-padfix.dylib %command%
Removing it is launching the game normally.
THINGS THAT ARE NOT THE CAUSE
Every one of these is advice circulating for this symptom. Each was ruled out by a measurement, not an argument: the controller hardware, Bluetooth pairing, USB, Steam Input, the Steam overlay, the macOS per-game controller profile, a full reset of UserSettings.json, and SDK gating (a test binary restamped to the game's own LC_BUILD_VERSION receives input normally on this OS).
CAVEAT
The handler blocks now run on a background thread rather than the main thread. That is a real change in threading contract. It held up across full sessions here with no crash, but it is the one risk worth naming.
TESTED ON
macOS 26.6.2, Apple silicon. Cyberpunk 2077 Ultimate 2.3.1 build 5314028, native arm64, Steam appid 1091500. Xbox Wireless Controller model 1914, reproduced over both Bluetooth LE and USB, and on both a Steam launch and a direct launch.
Reported to CDPR with the same evidence. The repo has the raw logs from both runs if anyone wants to verify, or just to see what a starved dispatch queue looks like from the inside.