Mac Developer Tools Permission: What It Grants and Who Should Have It

The Developer Tools entry in System Settings → Privacy & Security is the one most users will never need to touch. But if you write code, run a development environment, or use container tools, you’ve almost certainly granted it to at least Terminal, iTerm2, or your IDE. And like every other privacy toggle, the list grows over time and almost nobody audits it.

Here’s what it does, who legitimately needs it, and how to keep it tidy.

What Developer Tools permission grants

When an app has Developer Tools on, code that runs under that app is exempted from some of the runtime protections macOS applies to other binaries. Specifically:

• Apps it spawns can be unsigned or have invalid signatures
• Apps it spawns can call certain restricted APIs that signed apps from the App Store can’t
• The runtime hardened-runtime checks are relaxed for child processes

It does not mean:

• The app itself bypasses Gatekeeper at install time
• The app can read other apps’ files automatically
• The app gets access to your Photos, Contacts, or Camera

This permission exists because a development workflow often involves running binaries you just compiled — binaries that haven’t been through Apple’s signing and notarization pipeline. Without Developer Tools on for your terminal or IDE, every ./my-binary would trigger Gatekeeper and you’d be stuck right-clicking through “Open Anyway” prompts.

Who legitimately needs it

The short list:

• Terminal apps — Terminal.app, iTerm2, Warp, Alacritty, Kitty, Hyper
• IDEs and editors — Xcode (auto-granted in some cases), VS Code, JetBrains products (IntelliJ, PyCharm, GoLand, etc.), Sublime Text, Vim/Neovim wrappers
• Container and VM tools — Docker Desktop, OrbStack, UTM, Parallels, VMware Fusion
• Build tools sometimes — fastlane runners, CI agents you run locally

If you don’t write code or run containers, you probably don’t need anything in this list. Many users will have an empty list, and that’s fine.

Where to find it

Open System Settings → Privacy & Security → Developer Tools. It’s near the bottom of the privacy section. The list shows apps with the toggle on. Each can be flipped off independently.

Worth noting: the list won’t always show every dev tool you have installed. macOS only adds an app here once it’s actually requested the permission. So you might have Sublime Text installed and not see it in the list — that means it hasn’t yet asked, which means you haven’t tried to run an unsigned binary from inside it.

Audit your permissions in one screenSweep shows every app’s permissions on one page. Revoke in one click. Get Sweep free →

When you’d want to revoke it

A few realistic scenarios:

1. You stopped using an old IDE. The toggle is still on for it. Turning it off does nothing to your current workflow and removes a privilege from a binary you don’t open anymore.

2. You installed a development tool while troubleshooting a one-off thing — say, Charles Proxy or a network analysis tool — and you’ve never opened it since. Turn off, and either uninstall or leave dormant.

3. You’re handing the Mac to someone who doesn’t write code (kid, partner). Clearing the list is part of normalizing the machine for non-dev use.

The audit is fast. There are usually two or three legitimate entries.

What about Xcode?

Xcode’s relationship with Developer Tools is a little different. Apple’s first-party Xcode handles much of its own signing and runtime relaxation through entitlements. You’ll often see Xcode in the list, and you should leave it alone if you’re an iOS, macOS, or visionOS developer. Even if you’re not currently shipping anything, Xcode is needed for the command-line tools (xcode-select, the SDK headers, etc.) that other parts of the system rely on.

If you’re not a developer at all and you installed Xcode once for a tutorial three years ago, it might be worth fully uninstalling — Xcode is huge (15+ GB) and you’d reclaim the space. The privacy toggle resets when the app goes.

The relationship with Gatekeeper

Gatekeeper is the system-wide check that runs when you open an app. It looks for codesigning, notarization, and quarantine attributes (the com.apple.quarantine extended attribute that gets set when you download something).

Developer Tools permission doesn’t bypass Gatekeeper for user-launched apps. If you double-click an unsigned app in Finder, Gatekeeper still trips. What it does is allow your terminal or IDE to spawn unsigned binaries without the runtime tripping. That’s a meaningful distinction. The toggle isn’t a master Gatekeeper-off switch.

You can see what Gatekeeper thinks of any binary with:

spctl -a -vv /path/to/binary

A signed, notarized app shows “accepted source=Notarized Developer ID.” An unsigned one shows “rejected” plus a reason.

See what your apps actually accessSweep surfaces every camera, mic, file, and location permission on your Mac. Download Sweep free →

Sandbox containers and dev tools

Apps from the Mac App Store run in a sandbox by default — their files live in ~/Library/Containers/<bundle-id>/Data/. App Store apps can’t have Developer Tools permission because the sandbox prohibits the kind of child-process spawning the permission would enable. That’s why Xcode (which is on the App Store) handles things through entitlements instead.

Dev tools you grab outside the App Store (most of iTerm2, JetBrains, Docker, OrbStack) are not sandboxed. They get the full filesystem reach by default, plus Developer Tools access on top.

This isn’t bad — it’s just the trade-off for the kind of work these apps do. But it means your dev tools have more reach than your average Mac App Store utility, which is one more reason to keep the Developer Tools list tight.

What about command-line tools you install with Homebrew?

Homebrew installs to /opt/homebrew (Apple Silicon) or /usr/local (Intel). Binaries there are typically not signed by their original developers. They run from your terminal, and your terminal is what needs the Developer Tools permission to spawn them.

If your Terminal or iTerm2 has the toggle on, brew-installed binaries run normally. If not, you’ll occasionally trip Gatekeeper on individual binaries when you first run them. The fix in that case is xattr -d com.apple.quarantine /opt/homebrew/bin/<binary> for the specific tool, or just turning Developer Tools on for your terminal.

How often to audit

The cadence here can be looser than for Accessibility or Screen Recording — once a year is fine for most developers. The list grows slowly and the entries are usually all things you legitimately use.

Two events make a good time to audit:

1. After macOS major upgrades (the list sometimes gets reshuffled)
2. When you change jobs or switch tech stacks (old dev tools you’ve stopped using can be cleaned up)

Quick checklist

• Open System Settings → Privacy & Security → Developer Tools
• Confirm each entry corresponds to a tool you currently use
• Turn off entries for tools you’ve stopped using
• Consider uninstalling any IDE you haven’t opened in 6+ months
• If your list is empty, leave it that way

Skip System Settings — see it all at onceSweep collapses the privacy maze into one screen. Try Sweep free →

Developer Tools is one of those permissions where the right list might be zero entries, two entries, or six entries depending on what you do with your Mac. The audit isn’t about removing things — it’s about confirming the list reflects how you actually use the machine.