Why is my Mac running hot?

Yes. Each release is signed with an Apple Developer ID and notarized by Apple, and the notarization ticket is stapled to the disk image, so Gatekeeper opens it without an "unidentified developer" warning. Open the DMG, drag HeatLens to Applications, and launch it. If you want to check for yourself before opening:

spctl -a -t open --context context:primary-signature -vv HeatLens.dmg

Because it only reads what macOS already lets any app read about running processes: process IDs, parents, start times, executables, CPU and memory counters, and for your own processes the command line and working directory. That is enough to explain most heat and pressure. It does not request Full Disk Access, Accessibility, Screen Recording or an admin password, and it would not learn anything useful from them.

The one exception is optional: if you turn on the thermal alert, macOS asks once whether HeatLens may show notifications.

The flip side is what it can't see: details of root and other users' processes, kernel_task's numbers, the chip temperature, and GPU load. Those places show Not accessible or Unavailable.

Not by default. Out of the box HeatLens has no timers and no polling; it scans when you click Scan now, or once when macOS reports serious heat if you turned on the optional thermal alert. If you turn on Keep watching in the background, it samples every 30 seconds on power and 60 on battery (more often while something is busy, every 120 seconds in Low Power Mode), at a cost of a fraction of a percent of one core; Quit stops it. Measured on the development Mac, the idle app sits at 0.0% CPU with no change in CPU time between samples, and about 18 MB of memory as reported by top. A scan costs about one second of CPU spread over its five to ten seconds. Launch at login is off by default.

HeatLens itself makes no network connections apart from the update check you click; the MCP server runs on your Mac over standard input and output. But whatever the agent receives, it sends to its own model provider, as with anything else you show it. That's why the reports it gets are redacted: personal paths are replaced, and specific network addresses are left out. You choose whether to connect one, and you can remove it with claude mcp remove heatlens.

A sheet shows the PID, command, project and measured impact, and warns that stopping a dev server or agent can interrupt tests, edits, builds or active sessions. Cancel is the default. If you click Send SIGTERM, HeatLens re-reads the process from the kernel, checks that the PID still has the same start time and still belongs to you, and sends one SIGTERM. It waits a few seconds and tells you whether the process exited, is still running, had already exited, or had been replaced by another process, in which case nothing is sent. It never escalates to SIGKILL; for that, it points you to Activity Monitor. When one project has several leftovers, Stop leftovers lists them in one sheet with a checkbox each, and each selected process goes through the same check and single SIGTERM, one at a time.

A sandboxed build sees much less: it cannot list all processes, read physical memory footprints, or fall back to ps for system processes. That would make the diagnosis mostly guesswork, so HeatLens ships as a notarized direct download instead. It still runs under the hardened runtime, and the source is on GitHub if you'd rather build it yourself.

Quit HeatLens from the popover, then drag it from Applications to the Trash. If you had turned on Launch at login, turn it off first in the app's Settings, or remove it under System Settings, General, Login Items. The only other thing it leaves behind is its settings file:

~/Library/Preferences/dev.heatlens.HeatLens.plist

Delete that too and nothing remains.

Not yet. HeatLens targets macOS 14 or later on Apple Silicon, which is where it has been measured and tested.