Headlamp 0.33.0 on Mac ARM is broken

[joaquimrocha]

Describe the bug

A couple of people have reported that the last version, 0.33.0, is broken on Mac ARM. The OS says the file is corrupted.

Environment (please provide info about your environment):

• Installation type: Mac / Brew or direct installation

[joaquimrocha]

cc/ @illume for HW availability.

[kierr]

I am on a Mac Mini M4, Sequoia 15.5, installed via brew. Having upgraded via brew all was fine.

I just removed and reinstalled with brew to test this and you are correct - corruption error shows.

It can be fixed with xattr -dr com.apple.quarantine /Applications/Headlamp.app as per the docs.

user@mini ~ % codesign --verify --deep --strict --verbose=2 /Applications/Headlamp.app
/Applications/Headlamp.app: code has no resources but signature indicates they must be present
user@mini ~ % spctl --assess --type execute --verbose /Applications/Headlamp.app
/Applications/Headlamp.app: code has no resources but signature indicates they must be present
user@mini ~ % codesign -dvv /Applications/Headlamp.app
Executable=/Applications/Headlamp.app/Contents/MacOS/Headlamp
Identifier=Electron
Format=app bundle with Mach-O thin (arm64)
CodeDirectory v=20400 size=513 flags=0x20002(adhoc,linker-signed) hashes=13+0 location=embedded
Signature=adhoc
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements=none

The release notes for 0.33.0 show no warning about unsigned binaries as previous releases did - was this an oversight?

Nothing about the signature is different compared to the previous release (.dmg from brew cache):

user@mini downloads % codesign -dvv /Volumes/Headlamp\ 0.32.0-arm64/Headlamp.app
Executable=/Volumes/Headlamp 0.32.0-arm64/Headlamp.app/Contents/MacOS/Headlamp
Identifier=Electron
Format=app bundle with Mach-O thin (arm64)
CodeDirectory v=20400 size=513 flags=0x20002(adhoc,linker-signed) hashes=13+0 location=embedded
Signature=adhoc
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements=none
user@mini downloads % pwd
/Users/user/Library/Caches/Homebrew/downloads

It's possible that on macOS latest, unsigned/bad signature UI warnings are now just reporting the binary 'corrupt' which is confusing users.

One easy way of avoiding confusion for new users, would be to update the aforementioned docs page to use brew install --cask --no-quarantine headlamp. Another, would be to add a caveat block to the cask. I'll submit PRs for both.

BTW I'm always open to make macOS ARM HW available for the project, in case you ever need another cc.

[agardnerIT]

[abangser]

👋 I am a person who has hit this (same screenshot as @agardnerIT). I am curious about the solution to use --no-quarantine as I can see that as a way to get started quickly, but feels like an anti-pattern as the long term solution.

[agardnerIT]

I've just tried running:

brew install --cask --no-quarantine headlamp

and I get:

% brew install --cask --no-quarantine headlamp
Warning: Not upgrading headlamp, the latest version is already installed

So that's not a fix that works after the fact.

I agree with @abangser - feels dangerous to be advocating for unsigned binaries.

[abangser]

Yea @agardnerIT you need to uninstall first via Brew then run. That did work for me:

brew uninstall headlamp
brew install --cask --no-quarantine headlamp

Edit: You may also need to delete the application data directory which is ~/Library/Application Support/Headlamp for me. This was sticking around and caused some errors when I tried re-installing.

[joaquimrocha]

Oh! Nice, I thought this was a different issue than the quarantine due to the app not being signed (a user had reported that they did run the xattr command and it still failed for them). I check if that user can try this brew option (thanks for that suggestion!).

[kierr]

👋 I am a person who has hit this (same screenshot as @agardnerIT). I am curious about the solution to use --no-quarantine as I can see that as a way to get started quickly, but feels like an anti-pattern as the long term solution.

Yes it's definitely not a long term solution... but for now there are no others to suggest! For developers on macOS, the habit of xattr -c is an ugly anti-pattern faced daily 🙃

There is always the option of building from source if prebuilt binaries are untrusted.

If you have previously cleared xattr/quarantine for /Applications/Headlamp.app, when you do a brew upgrade you won't need to do it again, unless you uninstall or move the .app. Not sure why but that seems to just be how brew/macOS works at the moment.

I've just tried running:

brew install --cask --no-quarantine headlamp

and I get:

% brew install --cask --no-quarantine headlamp
Warning: Not upgrading headlamp, the latest version is already installed

So that's not a fix that works after the fact.

I agree with @abangser - feels dangerous to be advocating for unsigned binaries.

If you have headlamp already installed, you can use xattr -dr com.apple.quarantine /Applications/Headlamp.app, it is basically the same as installing with --no-quarantine.

I don't think anyone here is advocating unsigned binaries, but it's nice to be able to help others quickly get things working/installed when they are stuck.

You can also check the official docs, there's a banner on the homepage about unsigned binaries: https://headlamp.dev/docs/latest/installation/desktop/

Thanks to all devs and contributors!

[agardnerIT]

Nice! Thanks. I'll try the above and if you don't hear from me, it worked :)

[joaquimrocha]

I don't think anyone here is advocating unsigned binaries, but it's nice to be able to help others quickly get things working/installed when they are stuck.

Definitely. And thank you so much for your help @kierr . We were hoping this unsigned situation was for a very short while and it turned out not to be the case. I am currently looking for solutions as I agree we cannot continue like this much longer.

[Vad1mo]

Downloaded the dmg version 0.35, app can't start. Marked as broken. Usually it is possible to run applications following the process outlined in https://support.apple.com/en-us/102445

However, with Headlamp this isn't possible. As there is no Allow Anyway button in system settings.

So the only working solution is xattr -dr com.apple.quarantine /Applications/Headlamp.app

This bug causes many entry users to drop off from using Headlamp...

[kierr]

Downloaded the dmg version 0.35, app can't start. Marked as broken. Usually it is possible to run applications following the process outlined in https://support.apple.com/en-us/102445

However, with Headlamp this isn't possible. As there is no Allow Anyway button in system settings.

So the only working solution is xattr -dr com.apple.quarantine /Applications/Headlamp.app

This bug causes many entry users to drop off from using Headlamp...

This is normal across many applications that are unsigned. It also happens if you modify an application or build from source. MacOS used to provide several fast-and-easy workarounds but they added in a few hoops to jump through, to protect people (and non developers) from mindlessly bypassing safeties.

I believe the 'Allow Anyway' option is only shows when it's an unsigned binary that is from a 'known' developer. Without the developer being known/trusted, there is no simple bypass.

It's a pain, I know, but I don't think macOS users are going to 'drop off' from using Headlamp as a result... I mean, come on... Kubernetes itself could arguably be described as one of the most frustrating 'head banging' things to work with, even to someone with many years of experience. The irony is, if it's too hard for a user to troubleshoot their way to running an xattr to get past gatekeeper... for their own sanity, it's probably in their best interest!

[point-source]

I am getting this warning when installing headlamp via brew: Warning: headlamp has been deprecated because it does not pass the macOS Gatekeeper check! It will be disabled on 2026-09-01

I am aware that there are methods to workaround this (xattr, --no-quarantine) but I do not personally find them to be an acceptable solution. My opinion is that we should be properly signing the software. I applaud homebrew for taking steps to motivate a real solution.

Just wanted to update this ticket to reflect the new priority / urgency from the fact that homebrew, which is recommended on the homepage for this tool, considers this package deprecated. It made me do a double-take and come to the repo just to make sure the project wasn't abandoned. I very nearly just skipped over it due to the deprecation flag alone in the cask search results. I do expect this will impact headlamp adoption in time.

[SgtPooki]

Headlamp 0.39.0 is failing with this on an M1 mac:

tried install via brew, official website, and github releases. same error in all places.