Why Music.app Broke Every Automation on macOS Tahoe

If you have scripts, Shortcuts, or apps that automate anything in Apple Music, there is a good chance they stopped working when you updated to macOS Tahoe. Playlist scripts that played the full queue now stop after the first track. Scripts that read the current track fail for anything that isn't in your local library. And for anyone trying to keep artwork in sync between their files and Music.app, the automation path is gone entirely.

No deprecation notices. No migration guide. The Tahoe release notes don't mention any of it.

What stopped working

The breakages aren't subtle. They're fundamental operations that AppleScript has supported in iTunes and Music.app for over a decade.

Playlist playback. Tell Music to play user playlist "My Playlist" and it plays one song, then stops. This was reported widely on Apple Community and the Apple Developer Forums within days of Tahoe shipping. Apple fixed it in 26.1, but the pattern is telling: a core scripting operation broke silently and stayed broken for months.

Current track access. get name of current track now fails for any song not in your local library. Autoplayed tracks, Radio content, anything from the Home or New tabs. If you had a script that displayed now-playing info, logged listens, or synced state to another app, it broke. MacScripter documented that this only works reliably from the Songs tab now.

iTunes tell blocks. Any script that still used tell application "iTunes" in place of tell application "Music" stopped compiling entirely. Apple had silently mapped the old name for years. That mapping is gone.

Artwork writes. This is the one that matters most for collections. We built Private Press to sync artwork back to Music.app after pressing it into your files. When we tested on Tahoe, every artwork write command failed. Setting artwork data. Creating new artwork objects. Deleting and recreating them. The handlers reject the operations. There is no known combination of AppleScript syntax that writes artwork into Music.app on Tahoe.

This isn't new. It's accelerating.

Artwork access through AppleScript has been fragile for years. Doug Adams, who has maintained the largest collection of Music.app AppleScripts for two decades at dougscripts.com, has documented artwork handler bugs going back to Catalina. Secondary artwork access has been broken since 2019. Cloud-provided artwork has never been accessible through scripting. Each macOS release narrows what you can reach.

Tahoe isn't an anomaly. It's the current position on a trajectory. The scripting dictionaries haven't changed, according to diffing done by the MacScripter community. The commands are still listed. They just don't work the way they used to, or at all.

Why the platform is moving this direction

Music.app is built around a model where the cloud index is the source of truth. When you open an album, the artwork comes from Apple's cache, managed by a system service called AMPArtworkAgent. The metadata comes from Apple's catalog match. Your file is a local copy that the system may or may not consult.

In that model, external tools writing artwork into the Music.app layer is a complication. Your script might write a different image than the one Apple's catalog associates with that album. It might conflict with iCloud Music Library's sync state. Removing write access simplifies the system from Apple's perspective.

This is the same pattern described in Why Apple Music Artwork Disappears When You Move Your Collection. The artwork you see isn't in your files. It's in a cache you don't control. And with each macOS release, you have less ability to influence that cache programmatically.

What this means for your collection

If you relied on automation to manage artwork in Music.app, you need a different approach. The AppleScript path was never guaranteed, and on Tahoe it's functionally closed for writes.

The embedded artwork in your actual audio files is unaffected by any of this. MP3, M4A, FLAC, AIFF. The metadata containers in those formats are open standards. No platform update can change what's embedded in a file you own. An MP4 covr atom written in 2024 reads exactly the same in 2026, on any player, on any OS.

The question is how to keep Music.app's display consistent with what's in the file, now that the obvious automation path is gone.

Private Press handles this by working with the platform instead of against it. After pressing artwork into your file, it tells Music.app to re-read the file from disk. No artwork data passes through AppleScript. No broken handlers are involved. Music.app simply picks up what's already embedded, updates its cache, and displays the correct cover.

This works because the artwork is already in the file. The file is the source of truth. Private Press doesn't depend on Music.app's cooperation to write artwork. It depends on Music.app's ability to read a file, which is about as fundamental as it gets.

Building for what you control

This is one of the reasons we built Private Press. Not because AppleScript broke on Tahoe specifically, but because depending on platform automation to manage your own music was always fragile. The tools you use to manage your collection shouldn't depend on Apple continuing to support a particular scripting pathway.

Your files are yours. The containers are open. The formats are documented. What you press into them stays there, on every device, in every player, regardless of what macOS 27 decides to support or drop.

We build for people who own their music and want it to be right. The kind who notice when track five has the wrong genre tag. The platform is welcome to come along, but we don't wait for permission.