[terra-alex]

Closes #16685

Supersedes #14551, which was auto-closed while the CLA and issue link were pending. Same one-line change, rebased on current master.

Problem

macOS attributes a child process's TCC privacy request to the responsible process — the terminal. When a CLI launched inside Warp calls CoreBluetooth, macOS looks in Warp's Info.plist for NSBluetoothAlwaysUsageDescription; when it's absent the child is killed with SIGABRT:

This app has crashed because it attempted to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSBluetoothAlwaysUsageDescription key…

and the user has no way to grant Bluetooth access. This breaks every BLE tool run from Warp (bleak/pyobjc scripts, BLE CLIs, etc.).

script/update_plist already declares the sibling TCC usage strings — AppleEvents, Camera, Microphone, Contacts, Calendars, Reminders, Location, PhotoLibrary. Bluetooth is the one omission.

Fix

One line, matching the existing pattern:

plutil -insert NSBluetoothAlwaysUsageDescription -string "A program in Warp wants to use Bluetooth." "$WARP_PLIST_PATH"

Why the string alone is sufficient (no entitlement change)

iTerm2 fixes the identical issue with the string alone (added in iTerm2 3.5.0). Its code-signing posture is the same as Warp's — Developer ID + hardened runtime, shipping com.apple.security.device.camera and com.apple.security.device.audio-input but no com.apple.security.device.bluetooth — and BLE tools run from it without SIGABRT. The hardened-runtime device entitlement governs the entitled process's own direct access; the hosted CLI is a separate process and only needs the responsible app's usage string. So script/Entitlements.plist does not need to change.

The string is inert until a hosted process actually calls CoreBluetooth — it does not make Warp itself request Bluetooth on launch.

References

• Addresses Info.plist is missing NS*UsageDescription #1183 (requested these keys; Bluetooth specifically was never fixed — see the "core issue persists" comment)
• Addresses can't execute programs using bluetooth #6675 ("can't execute programs using bluetooth")
• Follows Add Reminders and full-access EventKit usage descriptions to Info.plist #13608 (merged), which added the EventKit/Reminders usage strings to this same file
• Precedent: iTerm2 added NSBluetoothAlwaysUsageDescription in 3.5.0 (iTerm2 issues Opt-in: bare left-drag selects in TUI without holding Shift on macOS #10353 / spec(GH9731): address Oz review on search scope, name normalization, Seti provenance #10360)

Manual testing

A controlled A/B on macOS 26.4.1 (Apple Silicon). There are two minimal app bundles, identical except for this one Info.plist key. Each spawns a child shell that runs a CoreBluetooth script, the same responsible-process relationship as Warp → shell → CLI. The script creates a CBCentralManager and runs the run loop for 4 s.

Bundle	NSBluetoothAlwaysUsageDescription	Child result
BLEProbeNoKey.app	absent	killed, exit 134 (SIGABRT). Crash report namespace: TCC, "must contain an NSBluetoothAlwaysUsageDescription key", the same report Warp produces today
BLEProbeWithKey.app	present	runs normally, CBManagerState 5 (poweredOn), exit 0

The same script under the current Warp release (v0.2026.10.21.08.25.02) is killed with the identical TCC termination (responsibleProc: "stable"). Under iTerm2, which ships this key, it runs. That confirms the usage string alone is what TCC requires; no entitlement change is needed.

I have not built Warp itself from source for this check. The change is a single plutil -insert line identical in form to the ten existing ones above it.

[cla-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have the users @terra-alex on file. In order for us to review and merge your code, each contributor must visit https://cla.warp.dev to read and agree to our CLA. Once you have done so, please comment @cla-bot check to trigger another check.

[terra-alex]

@cla-bot check

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!