Devastated. I have been looking for this forever....

[davewd]

But the App is buggy and doesn't work signing into Github, when i try to download the iupdate it fails and i have to uninstall and retry.

Is this the new standard of AI built software :( !?

[davewd]

@steipete - please fix !

Description
After updating RepoBar to the latest version (via the in-app update prompt), the app no longer launches. On first install through Homebrew everything worked correctly. The problem only appeared after accepting the updater dialog inside the app.

Finder only shows:

The application "RepoBar.app" can’t be opened

Image
Launching the binary directly:

"/Applications/RepoBar.app/Contents/MacOS/RepoBar"
zsh: killed
System log shows the actual reason:

amfid: /Applications/RepoBar.app/Contents/MacOS/RepoBar not valid:
Error Domain=AppleMobileFileIntegrityError Code=-413 "No matching profile found"
Code has restricted entitlements, but the validation of its code signature failed.
Security policy would not allow process: /Applications/RepoBar.app/Contents/MacOS/RepoBar
Gatekeeper assessment succeeds:

spctl --assess --verbose "/Applications/RepoBar.app"
→ accepted, notarized Developer ID
The app is signed and notarized, but AMFI rejects it due to restricted entitlements without a matching provisioning profile.

Steps to reproduce
Install RepoBar via Homebrew.
Launch RepoBar (works).
Accept the in-app update prompt.
Try launching RepoBar after the update.
App is killed immediately and cannot be opened.
Environment
macOS 15.7.3 (24G419)
Initial install: Homebrew
Update method: in-app Sparkle updater
RepoBar version: latest as of Jan 22, 2026
Expected behavior
RepoBar should launch normally after updating.

Actual behavior
macOS kernel kills the process at launch due to signature/entitlement mismatch.

Notes
Ad-hoc re-signing does not fix the issue. The shipped build appears to include restricted entitlements that are not allowed for third-party apps. A fresh build with corrected entitlements and signing should resolve the problem.

https://asshzacrq.blogspot.com/?page=en-git-steipete-repobar-1769070690419

[steipete]

Yup, on my list. openclaw is more important rn.

…

On Tue, Feb 3, 2026 at 4:06 PM davewd ***@***.***> wrote: *davewd* left a comment (steipete/RepoBar#36) <#36 (comment)> @steipete <https://github.com/steipete> - please fix ! Description After updating RepoBar to the latest version (via the in-app update prompt), the app no longer launches. On first install through Homebrew everything worked correctly. The problem only appeared after accepting the updater dialog inside the app. Finder only shows: The application "RepoBar.app" can’t be opened Image Launching the binary directly: "/Applications/RepoBar.app/Contents/MacOS/RepoBar" zsh: killed System log shows the actual reason: amfid: /Applications/RepoBar.app/Contents/MacOS/RepoBar not valid: Error Domain=AppleMobileFileIntegrityError Code=-413 "No matching profile found" Code has restricted entitlements, but the validation of its code signature failed. Security policy would not allow process: /Applications/RepoBar.app/Contents/MacOS/RepoBar Gatekeeper assessment succeeds: spctl --assess --verbose "/Applications/RepoBar.app" → accepted, notarized Developer ID The app is signed and notarized, but AMFI rejects it due to restricted entitlements without a matching provisioning profile. Steps to reproduce Install RepoBar via Homebrew. Launch RepoBar (works). Accept the in-app update prompt. Try launching RepoBar after the update. App is killed immediately and cannot be opened. Environment macOS 15.7.3 (24G419) Initial install: Homebrew Update method: in-app Sparkle updater RepoBar version: latest as of Jan 22, 2026 Expected behavior RepoBar should launch normally after updating. Actual behavior macOS kernel kills the process at launch due to signature/entitlement mismatch. Notes Ad-hoc re-signing does not fix the issue. The shipped build appears to include restricted entitlements that are not allowed for third-party apps. A fresh build with corrected entitlements and signing should resolve the problem. https://asshzacrq.blogspot.com/?page=en-git-steipete-repobar-1769070690419 — Reply to this email directly, view it on GitHub <#36 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAOI7KPXAQC6CZWAQ6O74D4KEZYHAVCNFSM6AAAAACTT2EXSKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQNBUGQ3TAOBXGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[davewd]

#41

[davewd]

Yup, on my list. openclaw is more important rn.
…

ITs a signing issue - I have proposed a PR to add info to the README. Congrats on Openclaw

[Endogen]

I'm waiting for this too. Want to use it but can't.

BUT openClaw is more important ❤️ 🤝

[sqdshguy]

Workaround for anyone who wants the CLI working right now:

The problem is repobarcli ships with keychain-access-groups which is a restricted entitlement that needs a provisioning profile. Standalone binaries outside an .app bundle can't have that, so AMFI kills it. The apple-events entitlement also causes a password prompt loop.

You can re-sign the binary yourself with those two stripped out:

# copy the binary out
cp /Applications/RepoBar.app/Contents/MacOS/repobarcli /tmp/repobarcli

# write entitlements without the problematic ones
cat > /tmp/repobarcli.entitlements << 'EOF'
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.security.hardened-runtime</key>
    <true/>
    <key>com.apple.security.temporary-exception.mach-lookup.global-name</key>
    <array>
        <string>com.steipete.repobar-spks</string>
        <string>com.steipete.repobar-spkd</string>
    </array>
</dict>
</plist>
EOF

# re-sign ad-hoc
codesign --force --sign - --entitlements /tmp/repobarcli.entitlements /tmp/repobarcli

# put it on your PATH
cp /tmp/repobarcli /opt/homebrew/bin/repobar
chmod +x /opt/homebrew/bin/repobar

# nuke old keychain entries (they belong to the old signature so they just prompt forever)
security delete-generic-password -s "com.steipete.repobar.auth" 2>/dev/null
security delete-generic-password -s "com.steipete.repobar.auth" 2>/dev/null

# import your gh token instead of using repobar login
repobar import-gh-token

After that repobar repos etc all work fine. Should be a quick fix for a clanker to sort out in the Xcode build config.

For the actual fix, the build should probably just sign repobarcli with a separate entitlements file that doesn't include keychain-access-groups. The CLI can talk to the main app over XPC (it already has the mach-lookup exceptions for that) and use import-gh-token for auth