Trust center

Hedroom asks for a lot of trust: it can pause apps, move files to the Trash and, with your approval, set fan speeds. This page puts the checkable facts in one place, with the limits next to them.

Hedroom has not launched. Everything below describes what is built, tested and measured in the repository, not a service with users. The first signed build is not published yet, so the signing and update checks below are what the release is built to pass, not something you can run today.

• Where your data goes
• How it is delivered
• What it can touch
• How we test
• Verify it yourself
• More detail

Where your data goes

App names, usage, history and receipts stay on your Mac. This is every outbound connection the app makes, and it matches the privacy page.

Buy Pro opens this website's pricing page in your browser, and the app makes no request to it. On the website, buying Pro talks to the same license host and to Stripe, who process your card details; Hedroom never sees the card number and keeps only a hash of your key, your plan and status, your email, and the names of your Macs. The license service does not store IP addresses itself. The server it runs on keeps ordinary request logs that only we can read. The privacy page lists each step. The privileged helper has no networking code. The browser extension and its native host make no network requests. There are no analytics and no crash-report uploads in 1.0. Questions about data: privacy@hedroom.app.

How it is delivered

These are the release rules. The security page carries the same status note: they are built and reviewed, and a check on a signed release build is still to be done.

• Developer ID, Hardened Runtime, notarization. Releases are built to be signed with a Developer ID, run under the Hardened Runtime and notarized by Apple. The release script stops on a failed check, and scripts/verify-all.sh checks the bundle (Hardened Runtime flag, no risky entitlements, app sandbox off by design, helper plist and identifier).
• Signed updates. Updates come through Sparkle 2 over HTTPS and must carry Hedroom's own EdDSA signature as well as Apple's notarization. The update key has not been generated yet, so the updater stays off until it is.
• A signed process library. The list that explains processes is signed with Ed25519. Hedroom checks the signature and version before using a new copy and keeps the old one if the check fails.
• Not sandboxed, not on the Mac App Store. The sandbox does not allow pausing or relaunching other apps or reading their memory, which is the point of Hedroom. That is why the limits in the next section exist.

What it can touch

Before any pause, quit, relaunch or demote, one safety check runs. In plain words, it refuses when the app:

• is Hedroom itself, which is ignored silently;
• is signed by Apple or lives in a system folder. The one exception is an Apple app you use yourself, such as Xcode, which you can relaunch or quit with a click, never from a rule;
• is on your never-touch list;
• is the app you are using right now, when the request comes from a rule;
• is on a call, playing audio or using the microphone, or is a call app while a camera is on;
• is a backup app while a backup is running;
• is not known to handle being paused, when a rule asks and you did not pick it yourself;
• could lose work if relaunched while memory is critical, or when a rule asks to relaunch an app not known to be safe to relaunch;
• would be force quit without a second explicit confirmation.

Where Hedroom cannot tell (for example it cannot read the audio or camera state), automatic actions are refused, and a click asks you first. A refusal is shown as the reason, never as an error. Apple-signed processes inside a third-party app's group, such as WebKit helpers, are skipped one by one too.

Deleting is gated separately. Every deletion, Trash move or removal of Hedroom's own data needs a confirmation of that exact list of items, which works once and expires after 5 minutes. Rules, notifications, schedulers and library updates cannot ask for it, and a test fails if they try. Files go to the Trash and can be put back. Startup items are renamed, never deleted. See What Hedroom never does.

How we test

Tests, counted on 2026-10-15

These are counts of test declarations in the source tree on 2026-10-15, not a record of a particular run. Some declarations run several inputs, so the number of cases is higher. Every suite runs before a release through scripts/verify-all.sh, which also builds a fresh clone with warnings as errors, lints, scans for secrets and checks the app bundle. The refusal table above has a test for every row.

Overhead, measured

Hedroom's own cost is held to a budget and measured with a script in the repository. One Mac only: a MacBook Pro with an M3 Pro and 18 GB, macOS 27.0, a Release build. The 8 GB and 16 GB matrix has not been run.

What is not yet shown: the other tabs, the menu bar popover and Settings were not re-measured after the last fixes, the 30-minute memory-growth check did not finish, and the Mac was under memory pressure for much of the 30-minute run, so only part of it was at the budgeted 5-second pace. The first measurement of a closed window was 41.7% of a core. That was a real bug (closed windows kept redrawing), found by this measurement and fixed. The full write-up is kept with the benchmark results in the repository. The separate benchmark page covers the planned comparison with memory cleaners.

The independent audit

On 2026-10-14 the code was reviewed independently against its own documentation. It was a review of code and behaviour: a clean build from a fresh clone, launching the app and reading real data, and checking claims against code. It was not a penetration test and not a third-party certification. The verdict was that the engine, interface and tests are real and wired, and that the build was not release-ready.

• The most serious finding was that Apple and system processes could be grouped under a third-party app and then be paused or have their priority changed. That broke a core rule. The fix checks each process in a group on its own, and a test covers it.
• Other findings included a cleanup sheet that quit apps outside the safety check, paused apps that could stay frozen after a crash, signature checks that cost too much on each sampling tick, and website copy that claimed more than the code did.
• What the audit could not test live at the time: licensing (the store was not set up), updates (no key) and some notification actions.

Two follow-up reviews on 2026-10-15 looked at the browser connection, display changes and startup items (several fixes, a few items still open), and at every call that deletes or interrupts anything. The second one led to the deletion consent described above, and a test guard that makes live file, Keychain, launch and hardware calls refuse to run during tests. Two decisions about automatic pruning of Hedroom's own history were left open for the founder. Still to do on a signed build: the helper approval flow and the real code-signing requirement.

Accessibility audit

An automated audit walks the accessibility tree of every screen, sheet and popover. See the accessibility statement for the numbers and the gaps.

Verify it yourself

You do not have to take our word for any of this. These checks work on your own Mac. The signing checks apply to a signed release, so they only work once one is published.

1. Watch the connections. Use a network monitor such as Little Snitch, or list Hedroom's open network sockets in Terminal. The second command also matches the helper, whose name starts with Hedroom. You should see only the hosts in the table above.

   lsof -nP -i -a -c Hedroom

2. Read the signature.

   codesign -dv --verbose=4 /Applications/Hedroom.app
   codesign --verify --deep --strict --verbose=2 /Applications/Hedroom.app

   The first shows the identifier, the team and that the Hardened Runtime flag is set. The second prints nothing wrong if the app is intact.
3. Ask macOS whether it is notarized.

   spctl -a -vvv /Applications/Hedroom.app

   A notarized Developer ID build is reported as accepted.
4. Check the download. Compare the SHA-256 of the file you downloaded with the line on the download page. That line appears when a release is published.

   shasum -a 256 ~/Downloads/Hedroom.dmg

5. Check the helper has no extras. The helper is signed without entitlements, so this prints none.

   codesign -d --entitlements - /Applications/Hedroom.app/Contents/MacOS/HedroomHelper

6. Check the update settings. The feed address should be https and the hardware profile off.

   plutil -p /Applications/Hedroom.app/Contents/Info.plist | grep -E 'SUFeedURL|SUEnableSystemProfiling'

Requirements for running Hedroom: Apple Silicon, macOS 15 Sequoia or later. To report something you find, write to security@hedroom.app. We acknowledge a report within 72 hours.

More detail

• Privacy

  The full list of connections and who is responsible for your data.

• Security

  How updates are signed, what the helper can and cannot do, and how to report a problem.

• Accessibility

  What is built, what was audited and the known gaps.

• What Hedroom never does

  The rules built into the code.

• Terms

  The license, in plain words. Draft.

• Refunds

  How to ask, and what happens to your license.

• Open-source licenses

  The software Hedroom is built on.

• security.txt

  The machine-readable contact for security reports.