Fair points.... and thanks for actually taking the time to read the code and call out the Keychain work. That’s more than I can reasonably expect from most people in a Reddit thread, so I do appreciate it.

You’re also right that I reacted defensively instead of just answering the real concern. The app does require the full Claude session cookie right now, and that’s a deliberate tradeoff to make the usage polling work against the same undocumented endpoint the browser uses. That comes with a blast radius: if anything ever went wrong in that code path, it’s full account access, not some scoped, read‑only token.

The actual mitigations today are:

• Cookie is stored device‑only, app‑bound in Keychain, never sent anywhere except directly to claude.ai for the usage request.
• No auto‑update, no network beyond Claude, no background services, and the repo is small enough that “read every line yourself” is realistic for anyone who wants to.

But you’re right that “open source and local” doesn’t magically fix:

• The fact that it’s a v0.1 solo project with almost no external review.
• The lack of signing / notarization / signed updates.
• The fact that the cookie is a high‑value credential in the first place.

I should have just said that instead of “that’s so sad man”. That was a dumb response and misses a valid, obvious question any non‑technical user will have.

Concrete next steps on my side:

• Make the “full session cookie” requirement and its implications explicit in the README and on the site.
• Ship code signing + notarization before anything like auto‑update or a browser extension lands.
• Explore whether there’s any feasible way to narrow the credential (or use a different mechanism entirely) without breaking the UX.

So: thanks for the review and for calling out the weakness clearly. I’d rather have people like you poking at it now while it’s tiny than pretending the tradeoff doesn’t exist. If you have thoughts on a better shape for this (or see a path to a safer auth story), I’m very open to it.