Proposal
Add a deliberately constrained fan control to the existing Fan card:
- Automatic returns control to macOS
- Max Cooling runs every detected fan at its own hardware-reported maximum
This would not expose arbitrary RPM input. In particular, users could not request a lower-than-normal speed, so the feature cannot weaken the SMC's cooling target through the UI.
Safety and privilege boundaries
- disabled entirely on fanless Macs
- explicit confirmation before Max Cooling
- all detected fans change together; partial failure requests an automatic-mode rollback
- normal app termination restores automatic mode
- a crash can leave fans at maximum (noisy, but thermally conservative), never at an arbitrary low target
- the helper accepts only no-argument sampling,
--fan-max, and --fan-auto
- sudo is refused unless the helper and its parent directory are root-owned and not group/other-writable
- sudoers lists those three exact command lines rather than allowing arbitrary helper arguments
Validation limitation
The repository's documented test Mac is fanless, so encoding, response handling, helper failure behavior, app builds, and privilege checks can be automated, but physical fan actuation still needs maintainer/community verification on a fan-bearing Apple Silicon Mac before merge.
Proposal
Add a deliberately constrained fan control to the existing Fan card:
This would not expose arbitrary RPM input. In particular, users could not request a lower-than-normal speed, so the feature cannot weaken the SMC's cooling target through the UI.
Safety and privilege boundaries
--fan-max, and--fan-autoValidation limitation
The repository's documented test Mac is fanless, so encoding, response handling, helper failure behavior, app builds, and privilege checks can be automated, but physical fan actuation still needs maintainer/community verification on a fan-bearing Apple Silicon Mac before merge.