macOS: xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools)

Hi, it's BlueByte. The morning after a macOS upgrade you type git status and get xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun. Then make, clang, brew install and npm install fail the same way. Your repositories are fine and nothing needs reinstalling except one Apple package. We'll walk through what the shims are actually looking for, why an upgrade empties that directory, how to confirm which case you have, the fix per case, and how to make the next upgrade painless.

What xcrun is complaining about, and the shapes it takes

On macOS the developer commands in /usr/bin — git, clang, make, swift, python3 — are wrappers. Apple's Command Line Tools documentation calls them shims: each one asks for the active developer directory and runs the real tool from inside it. That directory is either /Library/Developer/CommandLineTools, where the standalone Command Line Tools package installs, or /Applications/Xcode.app/Contents/Developer when Xcode is selected. The error is xcrun saying the directory it was told to use has no xcrun inside:

xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun

The sibling appears when the selected path is Xcode and Xcode is gone:

xcrun: error: active developer path ("/Applications/Xcode.app/Contents/Developer") does not exist
Use `sudo xcode-select --switch path/to/Xcode.app` to specify the Xcode that you wish to use for command line developer tools, or use `xcode-select --install` to install the standalone command line developer tools.

Both mean the same thing: the pointer is set, the target is empty or missing.

Why a macOS upgrade empties the directory, and the other causes

A major macOS upgrade. This is the common one. Apple's own guidance is to check for a new Command Line Tools release after a macOS upgrade, because the installed package may be incompatible with the new macOS. In practice the upgrade leaves /Library/Developer/CommandLineTools present but without its usr/bin, so xcode-select -p still prints the path and every shim fails.

Xcode was deleted or moved. If xcode-select was pointed at /Applications/Xcode.app and you dragged Xcode to the Trash, renamed it to Xcode-15.app, or removed it to free disk space, the pointer dangles. You get the second message above.

The pointer was changed by hand. sudo xcode-select -s to a path that is not a developer directory, or a DEVELOPER_DIR environment variable exported in a dotfile or a CI job, overrides the system setting for that shell.

The install never finished. The Command Line Tools dialog was cancelled, or a download failed, leaving a partial directory. The package receipt tells you.

Check the path before you install anything

Three commands sort the causes, and none of them change anything:

xcode-select -p
ls /Library/Developer/CommandLineTools/usr/bin/xcrun
pkgutil --pkg-info=com.apple.pkg.CLTools_Executables
echo "DEVELOPER_DIR=${DEVELOPER_DIR:-unset}"

/Library/Developer/CommandLineTools
ls: /Library/Developer/CommandLineTools/usr/bin/xcrun: No such file or directory
No receipt for 'com.apple.pkg.CLTools_Executables' found at '/'.
DEVELOPER_DIR=unset

Pointer set, binary missing, no receipt — the package is gone and cause one applies. A receipt with a version: line but no binary is a broken directory, which needs the same fix. A pointer at Xcode.app that ls /Applications cannot find is cause two. A DEVELOPER_DIR that is not unset is cause three, and it wins over xcode-select for that shell.

Fix 1: install the Command Line Tools again

Ask macOS to fetch the package. Apple documents the command and the note it prints; a system dialog follows, and you click Install and accept the licence:

xcode-select --install

xcode-select: note: install requested for command line developer tools

The download is large — the package carries the full macOS SDK — and needs an administrator account. Nothing is broken if the command instead answers that the tools are already installed and points you at Software Update — the wording varies by macOS version — while the binary is still missing. That is the broken-directory case: remove the directory Apple's uninstall steps name, then request the install again:

sudo rm -rf /Library/Developer/CommandLineTools
xcode-select --install

Nothing of yours lives in that directory; it holds only Apple's toolchain and SDK, and the package recreates it. Software Update in System Settings, or softwareupdate --list, may also offer a Command Line Tools release for the current macOS; installing it from there is the same package.

Fix 2: point xcode-select at the Xcode you actually have

If Xcode is installed, you do not need the standalone package at all — Apple's docs are clear that Xcode bundles the same tools. Select it, or reset to the default search:

sudo xcode-select -s /Applications/Xcode.app
xcode-select -p

/Applications/Xcode.app/Contents/Developer

sudo xcode-select --reset clears a hand-set path and lets the shims find whichever developer directory exists. Both commands change the setting for every user on the Mac, which is why they need sudo.

Fix 3: an environment variable is overriding the system path

DEVELOPER_DIR takes precedence over xcode-select for the shell that has it set. Find where it comes from and remove it, or point it at a real directory:

grep -n DEVELOPER_DIR ~/.zprofile ~/.zshrc ~/.bash_profile 2>/dev/null
unset DEVELOPER_DIR
xcrun --find clang

This is also the right tool for CI: export DEVELOPER_DIR=/Applications/Xcode-16.app in the job instead of running xcode-select -s on a shared runner.

A real case: git dead after an overnight upgrade

A developer let a major macOS upgrade run overnight. In the morning git pull failed with the invalid active developer path message, and so did brew upgrade, which needs git. xcode-select -p still printed /Library/Developer/CommandLineTools; pkgutil --pkg-info reported no receipt. They ran xcode-select --install, clicked Install in the dialog, waited for the download, and git --version answered again with the Apple Git build for the new package. brew doctor was clean without any Homebrew change, because Homebrew had only been waiting on git.

Check it end to end and keep it from coming back

Verify with the shim, then with a tool that goes through it:

xcode-select -p
xcrun --find clang
git --version
pkgutil --pkg-info=com.apple.pkg.CLTools_Executables

/Library/Developer/CommandLineTools
/Library/Developer/CommandLineTools/usr/bin/clang
git version 2.x.y (Apple Git-nnn)
package-id: com.apple.pkg.CLTools_Executables
version: 26.x.0.0.1.…

The exact versions depend on the package Apple ships for your macOS. To stay ahead of the next upgrade: run xcode-select -p and git --version right after any major macOS update, before the first meeting; keep Software Update on so new Command Line Tools releases appear as updates; and if you rely on Xcode, select it explicitly so a stale standalone package cannot be the active path.

How this differs from "tool 'xcodebuild' requires Xcode" and the licence prompt

xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance is not a missing-tools problem: the Command Line Tools are installed and working, but xcodebuild and xctrace ship only with Xcode. Install Xcode and select it with Fix 2. And You have not agreed to the Xcode license agreements means everything is installed and the shims found it; run sudo xcodebuild -license once.

Next time you hit this, walk these checks back in order: xcode-select -p, ls the usr/bin/xcrun under that path, pkgutil for the receipt — and let xcode-select --install do the rest.