A little while ago, I posted here asking what you'd look for first in a redesigned CodexBar Lite.
The feedback was incredibly useful - especially around glanceability, keeping the app lightweight, and making sure a menu bar utility stays out of your way.
After using the redesign myself for a while and polishing the little things, it's now live.
The goal hasn't changed: keep CodexBar Lite minimal, privacy-first, and focused on doing one thing well.
I've just finished a pretty substantial UI refresh for CodexBar Lite and I'm using it myself before shipping it.
The functionality is largely the same. The focus this time wasn't adding features, it was making the app feel more polished while staying true to its original philosophy:
Minimal
Privacy-first
Native macOS
Before I hit release, I'm curious: If you were testing a menu bar app, what's the first thing you'd notice or judge?
What a week!
CodexBar Lite closed at #13 Product of the Day with 97 points.
For a first Product Hunt launch, I honestly couldn't have asked for more.
I want to thank everyone who supported the launch, whether you upvoted, commented, tried the app, shared feedback, or simply stopped by to take a look. Every interaction meant a lot.
The launch may be over, but the project certainly isn't.
does exactly one job well - shows Codex usage right in the menu bar without needing Chrome open or digging through Keychain. lightweight, doesn't need an API key since it reads off the existing CLI session.
would like to see some kind of integrity check on the auto-update payload given it's sitting there with visibility into a live coding session. otherwise solid for something this small in scope.
It would silently stop fail if OpenAI changes the session format. That said, I use it every day myself and have been maintaining it for almost 2 months now, so these issues usually get caught quickly.
I’ve also added OTA updates, which makes it easier to ship fixes whenever something changes on OpenAI’s end.
the no-Chrome, no-Keychain, no-API-key approach is a genuinely refreshing default for a tool this small in scope, most usage trackers ask for way more than they need. one thing I'm curious about since it's riding on your existing CLI session - does the polling itself count against anything on OpenAI's side, like a second process making periodic calls with your session credentials showing up as unusual activity, or is it reading something more like a local cache rather than actually hitting their API each refresh?
@galdayan That's a great question.
The app doesn't read usage from a local cache. It periodically makes the same authenticated request that you'd make yourself to check your usage, using your existing codex login session. It isn't creating a separate account or using a different authentication mechanism.
From OpenAI's perspective, it's just another authenticated request from your existing session, similar to if you checked your usage manually every few minutes. I also keep the refresh interval conservative to avoid unnecessary requests, and one could configure this interval as well.
Privacy-first design makes sense for a dev tool — anything touching an active coding session should be careful about what it asks for. The no-Keychain, no-browser-cookie approach is reassuring. I use a mix of AI coding tools across projects and the comparison question comes up constantly: when you are running both Codex and something like Claude Code in the same workflow, there is no easy way to see which got used for what and track where the actual productivity gain is. Is the session model specific enough to Codex that adding a second provider would need a separate app, or is the architecture flexible enough to slot in another CLI session alongside the Codex one?
@noctis06 That’s a really good question. Right now, the session model is intentionally Codex-specific because the app is built around Codex’s existing CLI authentication and usage data.
The architecture could support other providers, but I’d be careful about turning CodexBar Lite into a multi-provider dashboard, since that would go against the minimal focus.
My current thinking is that another provider would either be a separate lightweight companion app, or an optional integration that stays completely out of the way unless enabled.
The productivity comparison angle is interesting though. Tracking which tool was used for what would require much deeper session-level data than CodexBar Lite currently collects, and I’d want to approach that very carefully from a privacy perspective.
the no-Chrome no-Keychain angle is nice but the OTA auto-update piece is the part that'd actually worry me a little - an app that's already got a live coding session in view and can push its own updates is a decent supply chain target if the update channel or signing ever got compromised. is there any code signing/checksum verification on the update payload before it installs, or is it more of a basic download-and-replace flow right now
@omri_ben_shoham1 That's a fair concern. The app uses Sparkle for updates, so update payloads are cryptographically signed and verified before they're installed. If the signature verification fails, the update is rejected. The app is also code signed, so it isn't just a download-and-replace flow.
@wei_b0 - This looks amazing, any plans to build a similar app for Claude and other AI Platforms?
@codeandsea Definitely, I'd love to!
The only thing I'd be careful about is preserving the philosophy of the app - keep it minimal, focused, and avoid turning it into another bloated usage dashboard.
@codeandsea Totally understandable. I wonder if there's a nice middle ground where a single app can stay minimal but be configurable enough to support multiple AI platforms. That might solve the problem for both groups of users without sacrificing the original philosophy.
Loving the choice to lean on the existing CLI session instead of asking users to generate yet another API key, lovely detail that makes a tool feel trustworthy:)
CodexBar Lite
Thanks! Really appreciate you taking the time to try it and write this.
Good call on the update path. The app uses Sparkle for automatic updates, so update payloads are cryptographically signed and verified before installation rather than being a simple download-and-replace flow. Supply chain security is definitely something I take seriously, especially for a developer tool.
Glad the minimal, privacy-first approach resonated with you!