What can Radar monitor, and which permissions does it use?
Understand same-user TCP monitoring, optional requests, saved local data, and safe sharing of diagnostic details.
In this article
Understand the monitoring boundary
Radar reads macOS's native process information for processes owned by the same user as Radar. It detects listening TCP sockets with available command information and groups related processes. It does not need you to supply a directory of projects, and it does not read source files to recognize a server.
With unrecognized-server display off, a listener must match an enabled built-in or custom rule. With it on, unmatched accessible listeners can appear as Other. Bound addresses can include loopback, wildcard, and other interfaces. A listening socket alone does not prove HTTP support or application health.
There is no remote-machine, guest-process, Docker, VM, UDP-listener, or Unix-socket monitoring interface. Servers owned by another user are excluded. Host forwarding listeners may appear as host processes; their guest processes are not individually inspected.
Know when macOS is involved
The app's current UI has no Accessibility, Screen Recording, or Full Disk Access onboarding. It does not offer a permission-granting flow for native process scanning or an administrator escalation for stopping. Do not assume those permissions will fix a missing server.
Launch at login asks macOS to register or unregister the app's login item. The switch's starting value reflects that system state. A registration error is logged, without a dedicated in-app error dialog.
Notifications are optional. The first alert post requests macOS permission. To review that permission or presentation, use Settings… → Alerts → Open Notification Settings…. There is no Test Notification button or visible permission-status field.
HTTP readiness is also optional and off for a new project. Turning it on makes HEAD requests to the selected IP address, port, and HTTP/HTTPS protocol. It does not send browser cookies or saved credentials, fetch response bodies as a browsing session, follow redirects, or relax TLS validation.
Understand what is saved
General and Alerts options, plus project preferences, are saved in Radar's macOS user preferences. Custom rules and built-in enabled choices are saved in ~/Library/Application Support/Radar Dev Monitor/profiles.json.
Project preferences use the detected working folder's exact path. They include ignore, protection, alert snooze end time, selected endpoint, protocol, and readiness. If a project path is unavailable, the preference key uses the current process identity, so it is not a reliable cross-restart project setting.
Resource charts stay in memory, with at most 120 samples per current server within 30 minutes. Readiness results, previously observed parent chains, and per-server Stop reminding choices are also session observations rather than an exported history. The current UI has no sync, backup, profile export/import, diagnostic export, or reset-all control.
The current production source does not implement account sign-in, licensing, subscription management, or automatic app updates. Do not look for those settings in this build's menu.
Review diagnostic text before sharing it
Details can show local paths, PIDs, executable names, parent names, and command arguments. Radar redacts recognized credential flags and URL credential/query/fragment forms from displayed commands. It does not guarantee removal of every secret format, and custom rule terms may contain sensitive text you typed yourself.
Review copied commands, paths, profile files, and screenshots before sharing them. For a focused report, use the checklist in missing-server troubleshooting. There is no built-in upload of a diagnostic bundle in the current UI.