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.
CodexBar Lite
CodexBar Lite
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?
CodexBar Lite
@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?
CodexBar Lite
@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
CodexBar Lite
@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?
CodexBar Lite
@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.
CodexBar Lite
@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
@mohammed_messeguem appreciated!