You’re at your desk. You have a good microphone — a Shure, a Blue, an audio interface, whatever. Your AirPods connect, and without asking, macOS decides your input device is now the AirPods mic. Your next call sounds like you’re phoning in from a wind tunnel, and if you’re listening to music, it suddenly sounds like AM radio.
This happens because macOS re-evaluates the default input device whenever the device list changes, and Bluetooth headsets tend to win. There is no “never use this device as a microphone” checkbox anywhere in System Settings. Here’s why it happens and every way I know to fix it, from zero-effort to fully automated.
Why your music also sounds terrible when this happens
The mic switch has a second casualty: output quality. Classic Bluetooth can’t do high-quality stereo audio (A2DP) and microphone input (HFP) at the same time. The moment something opens the AirPods mic, the whole headset drops to the hands-free profile, and your music goes from fine to phone-call quality. People often notice the audio degradation before they notice the mic switch — if your AirPods ever suddenly sound awful mid-song, check your input device.
One wrinkle worth knowing: recent AirPods talking to recent Macs largely dodge this. Because Apple controls both ends of the link, they negotiate their own high-bandwidth two-way codec (AAC-ELD) instead of falling back to the ancient hands-free profile — so music drops from “great” to “very good” rather than off a cliff. It’s an Apple-to-Apple handshake, though: third-party Bluetooth headsets, and AirPods paired to non-Apple hardware, still take the full plunge. If your Sony or Bose cans sound dramatically worse on calls than your AirPods do, that’s the whole story.
So fixing the mic switch isn’t just about how you sound to others. It’s about how everything sounds to you.
Fix 1: The manual way (works today, forever annoying)
System Settings → Sound → Input → click your real microphone. That’s it — until the next time the device list changes. macOS remembers your choice only as long as the topology stays the same. AirPods disconnect and reconnect? You may be doing this again. This is the fix everyone knows, and the reason this article exists.
One adjacent setting worth checking: on your AirPods settings page (System Settings → click your AirPods while connected), set Connect to This Mac to When Last Connected to This Mac instead of Automatically. This doesn’t control the mic, but it stops the AirPods from aggressively jumping to your Mac when you put them in your ears for your phone, which is when a lot of surprise switches happen.
Fix 2: The command line way
Homebrew has a small utility called switchaudio-osx that can set audio devices from the terminal:
brew install switchaudio-osx
# list devices
SwitchAudioSource -a -t input
# set your input
SwitchAudioSource -t input -s "Shure MV7"
Handy on its own (bind it to a Raycast script or a keyboard shortcut), but the real value is that it’s scriptable — which leads to the actual fix.
Fix 3: The automated way (Hammerspoon)
Hammerspoon can watch for audio device changes and immediately put your input back. This is the closest thing to a real solution without buying anything:
-- ~/.hammerspoon/init.lua
local preferredMic = "Shure MV7"
local function enforceInput()
local current = hs.audiodevice.defaultInputDevice()
if current and current:name() ~= preferredMic then
local target = hs.audiodevice.findInputByName(preferredMic)
if target then
target:setDefaultInputDevice()
hs.notify.show("Audio", "", "Input restored to " .. preferredMic)
end
end
end
hs.audiodevice.watcher.setCallback(function(event)
if event == "dIn " or event == "dev#" then
hs.timer.doAfter(0.5, enforceInput)
end
end)
hs.audiodevice.watcher.start()
The half-second delay matters — macOS fires several device events during a Bluetooth connect, and acting on the first one sometimes gets overridden by the system a moment later.
The limitation: this is a hard pin. If you grab your MacBook and leave the desk, the script will keep trying to select a microphone that isn’t there (Hammerspoon handles the device being missing gracefully, but you get no intelligent fallback — you’re on the built-in mic by accident rather than by choice). A priority list — “Shure if it’s here, AirPods if not, built-in as last resort” — is what you actually want, and you can extend the script in that direction with a ranked table if you’re comfortable in Lua.
Fix 4: Apps that do this for you
- SoundAnchor (free) — does exactly this: you set a preferred device order and it enforces it. The UI is minimal and it hasn’t seen much love lately, but it works.
- SoundSource (Rogue Amoeba, paid) — the heavyweight. Per-app audio control, effects, and device management. Excellent software; more than most people need for this one problem.
What I’d actually recommend
If you’re technical: the Hammerspoon route. It’s free, transparent, and you’ll end up using Hammerspoon for five other things. If you’re not: SoundAnchor covers the basic case.
The deeper issue — that macOS treats audio input as a single global setting with no notion of preference or context — doesn’t have a great answer today. Which app should win when your conferencing app wants the AirPods for echo cancellation but everything else should leave your Shure alone is a genuinely unsolved problem on the platform. If you’ve built your own solution to this, I’d love to hear about it.