Submitted the link to HN where it rocketed to 504 points in hours, signaling broad recognition that the Apple Music auto-launch problem has plagued Mac users since Catalina in 2019. The strong upvote response suggests thousands of users had silently endured the issue and immediately recognized MusicDecoy as a clever, minimal solution.
Shipped a 3KB background-only agent that exploits how macOS routes media keys to whichever app most recently claimed MPRemoteCommandCenter. By silently registering as a now-playing client at login, MusicDecoy absorbs the keystroke before Apple Music can wake up, requiring no UI and no user configuration.
Frames MusicDecoy as a clean specimen of a broader pattern: on Catalina and later, the play/pause key is no longer a hardware event the user binds to an app of choice, but a system intent routed to a vendor-preferred handler. The editorial argues the only escape hatch is to write another app that races for the same hook — a workaround, not a real fix.
A developer publishing under lowtechguys.com shipped MusicDecoy, a Mac utility that exists for exactly one reason: to stop the Apple Music app from launching when you tap the play/pause key on an external keyboard, AirPods, or a Bluetooth headset. The app is a few kilobytes, runs as a background-only agent (`LSBackgroundOnly = true` in its Info.plist), has no UI, and does nothing except register itself as a now-playing client with the system.
The trick is that macOS routes the media key to whichever app most recently claimed the `MPRemoteCommandCenter` — so MusicDecoy claims it at login and then silently absorbs the keystroke. The Apple Music app never gets the event, so it never wakes up, never starts downloading your library, and never starts playing the last song you listened to in 2021. The HN thread hit 504 points within hours, which is the kind of signal that only appears when a fix lands for an annoyance that thousands of people had silently filed under "things I've stopped noticing."
The underlying bug isn't new. It's been broken since macOS Catalina killed iTunes in 2019 and replaced it with Music.app, which Apple wired into the media-key path at the OS level. Disabling launch agents, removing the app from `/Applications`, or even deleting it outright doesn't help — macOS re-resolves the binding and relaunches Music.app on the next keypress. There is no toggle in System Settings.
This is a small story about a small app, but it's a clean specimen of a pattern worth naming: default-vendor apps reclaiming OS-level hooks that used to be user-configurable. On Catalina and later, the play/pause key is no longer a hardware event you bind to an app of your choice; it's a system intent that gets routed to a vendor-preferred handler. The user-facing result is that a key on your keyboard physically launches software you don't want, every single time, and the only escape hatch is to write another app that races to claim the same handler.
Compare this to the Linux desktop, where MPRIS (the Media Player Remote Interfacing Specification) exposes media key routing as a D-Bus contract any app can implement and any compositor can route — no privileged default. Or to Windows, where the SMTC (System Media Transport Controls) API at least lets you uninstall the default player. macOS is the only major desktop OS where the workaround for "my play button opens an app I don't use" is "ship a decoy binary."
The community reaction on HN was telling. Top comments weren't about the code — they were variations of "I assumed this was impossible" and "I've been unplugging my keyboard for six years." One commenter pointed out that MusicDecoy is functionally identical to the long-defunct NoTunes project, which used a different mechanism (watching for Music.app launches and force-quitting it) that broke on every macOS update. MusicDecoy works because it uses the same public API Apple uses internally; there's nothing for a future macOS to "fix" without breaking third-party media players.
There's also the source-available angle. The author ships a notarized binary but the approach is documented end-to-end — the entire app is a few dozen lines of Swift that initialize an `MPRemoteCommandCenter`, set a no-op handler for `playCommand`, and call `MPNowPlayingInfoCenter.default().playbackState = .paused`. Anyone who reads the post can rebuild it from scratch in an afternoon. That's the right shape for a utility like this: small enough to audit, boring enough to trust.
If you're on macOS and you've ever cursed the Music app for hijacking your keyboard, install it. The cost is a 3KB background process and one login item. That's it.
If you're building a desktop app and you care about being a good citizen on someone else's machine, the lesson is sharper: the `MPRemoteCommandCenter` is a shared, last-writer-wins resource — claiming it without a user-visible UI is the same anti-pattern Apple Music is being punished for here. Register the command center when your app's playback view is visible. Release it when you go to the background. Don't squat on system intents to keep your app in the user's muscle memory.
For anyone shipping CLI tools, menu-bar utilities, or login agents on macOS, the MusicDecoy Info.plist is also worth reading as a reference: `LSBackgroundOnly`, `LSUIElement`, no main window, no Dock icon, no menu bar. It's the minimum viable Mac app, and it's the right shape for a lot of small utilities that currently ship as menu-bar apps because their authors didn't know they could go further. If your tool has no UI, don't fake one.
The broader point for practitioners: many "I just have to live with this" annoyances on closed platforms turn out to have a sub-100-line fix once someone reads the docs for the API the vendor uses internally. Catalina shipped in October 2019. The fix was always available. Nobody wrote it for six years because nobody believed it would be that easy.
Apple is unlikely to add a "choose your default media player" toggle to System Settings — that's the kind of thing Cupertino has historically only shipped under EU regulatory pressure, and media-key routing isn't on the DMA's radar. So MusicDecoy and its inevitable Homebrew cask will be the answer for the foreseeable future. The interesting second-order question is whether MPRIS-style explicit routing finally lands in macOS — probably not, but the fact that a 3KB decoy app went to the front page of HN suggests Apple's "we know best which app should play your music" stance is finally costing them goodwill among the developers who recommend Macs to everyone else.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.