Summary
VibeProxy launches (background processes start and stay running: CLIProxyMenuBar and cli-proxy-api-plus) but never shows a menu bar icon, so there is no way to access settings or quit the app via the UI. Confirmed reproducible on the latest release (1.8.280, today's build) as well as the prior 1.8.267.
Root cause found via Console/log investigation
log show --predicate 'eventMessage CONTAINS "CLIProxyMenuBar"' shows this repeating every time the app is opened:
tccd: [com.apple.TCC:access] TCCDProcess: identifier=com.vibeproxy.app, pid=<pid>, ... binary_path=/Applications/VibeProxy.app/Contents/MacOS/CLIProxyMenuBar attempted to call TCCAccessRequest for kTCCServiceAccessibility without the recommended com.apple.private.tcc.manager.check-by-audit-token entitlement
Checking the app bundle's entitlements directly:
$ codesign -d --entitlements - /Applications/VibeProxy.app/Contents/MacOS/CLIProxyMenuBar
Executable=/Applications/VibeProxy.app/Contents/MacOS/CLIProxyMenuBar
# (no entitlements printed at all)
The binary has zero entitlements in its code signature. Because of this, the Accessibility permission request the app makes at launch is malformed from TCC's perspective — it never resolves into a proper prompt or a grantable/deniable permission record. Confirmed this by checking both the user and system TCC databases directly (~/Library/Application Support/com.apple.TCC/TCC.db and /Library/Application Support/com.apple.TCC/TCC.db) — there is no kTCCServiceAccessibility row for com.vibeproxy.app in either, even after manually adding VibeProxy.app via System Settings → Privacy & Security → Accessibility. The manual add does not persist, presumably because the malformed request never gives TCC a valid identity to attach a grant record to.
RunningBoardServices logs confirm the app's actual runtime state matches this: it repeatedly cycles running-active-NotVisible, consistent with a process that's alive but never successfully becomes a visible UI element.
Reproduction
- Download and install VibeProxy (tested both 1.8.267 and fresh 1.8.280 from today's release)
- Launch normally (double-click or
open /Applications/VibeProxy.app)
- Background processes start (
ps aux | grep -i cli-proxy shows both CLIProxyMenuBar and cli-proxy-api-plus running, and the proxy itself is fully functional on 127.0.0.1:8318)
- No menu bar icon ever appears — no settings access, no quit option
log show --predicate 'eventMessage CONTAINS "CLIProxyMenuBar"' --last 1h shows the repeated TCC entitlement failure above every time the app becomes active
Environment
- macOS (Apple Silicon / arm64)
- VibeProxy 1.8.267 and 1.8.280 (both exhibit identical behavior)
- App bundle is correctly signed (
Developer ID Application: Automaze, Ltd. (GJ2RT96SZT), hardened runtime flag present) and not quarantined
Suggested fix
Add the required entitlements to the CLIProxyMenuBar binary's code signature — at minimum whatever is needed to make a well-formed kTCCServiceAccessibility request (the log message explicitly names com.apple.private.tcc.manager.check-by-audit-token as the "recommended" entitlement TCC expected but didn't find). This is likely a build/signing pipeline gap rather than an app-code bug, since the binary is otherwise properly signed.
This may be the same underlying issue as #389 ("MacOS 15.7.3 can not run" — "nothing happens" on launch), just without the diagnostic detail to pin down the cause there.
Summary
VibeProxy launches (background processes start and stay running:
CLIProxyMenuBarandcli-proxy-api-plus) but never shows a menu bar icon, so there is no way to access settings or quit the app via the UI. Confirmed reproducible on the latest release (1.8.280, today's build) as well as the prior 1.8.267.Root cause found via Console/log investigation
log show --predicate 'eventMessage CONTAINS "CLIProxyMenuBar"'shows this repeating every time the app is opened:Checking the app bundle's entitlements directly:
$ codesign -d --entitlements - /Applications/VibeProxy.app/Contents/MacOS/CLIProxyMenuBar Executable=/Applications/VibeProxy.app/Contents/MacOS/CLIProxyMenuBar # (no entitlements printed at all)The binary has zero entitlements in its code signature. Because of this, the Accessibility permission request the app makes at launch is malformed from TCC's perspective — it never resolves into a proper prompt or a grantable/deniable permission record. Confirmed this by checking both the user and system TCC databases directly (
~/Library/Application Support/com.apple.TCC/TCC.dband/Library/Application Support/com.apple.TCC/TCC.db) — there is nokTCCServiceAccessibilityrow forcom.vibeproxy.appin either, even after manually adding VibeProxy.app via System Settings → Privacy & Security → Accessibility. The manual add does not persist, presumably because the malformed request never gives TCC a valid identity to attach a grant record to.RunningBoardServiceslogs confirm the app's actual runtime state matches this: it repeatedly cyclesrunning-active-NotVisible, consistent with a process that's alive but never successfully becomes a visible UI element.Reproduction
open /Applications/VibeProxy.app)ps aux | grep -i cli-proxyshows bothCLIProxyMenuBarandcli-proxy-api-plusrunning, and the proxy itself is fully functional on127.0.0.1:8318)log show --predicate 'eventMessage CONTAINS "CLIProxyMenuBar"' --last 1hshows the repeated TCC entitlement failure above every time the app becomes activeEnvironment
Developer ID Application: Automaze, Ltd. (GJ2RT96SZT), hardened runtime flag present) and not quarantinedSuggested fix
Add the required entitlements to the
CLIProxyMenuBarbinary's code signature — at minimum whatever is needed to make a well-formedkTCCServiceAccessibilityrequest (the log message explicitly namescom.apple.private.tcc.manager.check-by-audit-tokenas the "recommended" entitlement TCC expected but didn't find). This is likely a build/signing pipeline gap rather than an app-code bug, since the binary is otherwise properly signed.This may be the same underlying issue as #389 ("MacOS 15.7.3 can not run" — "nothing happens" on launch), just without the diagnostic detail to pin down the cause there.