Claud useage is not visable

[agnuscloudgit]

Description

Since there was a technical issue with claud ai isn't the usage not visible anymore but now it works Claude with an open usage you don't see the usage still I have tried to restart it. I tried to restart my PC. But still nothing and all the other AI are working for example cursor ChatGPT and Gemini only one is claude that's not working

Steps to Reproduce

Open openusage
I've opened claude when I have installed it
I refreshed the time but still nothing

Expected Behavior

...

Actual Behavior

...

OpenUsage Version

0.6.9

Operating System

macOS (Apple Silicon)

Screenshots

Additional Context

No response

[TytaniumDev]

Also seeing this, happy to provide any logs or more detail if needed

[agnuscloudgit]

i dont know how to get any logs for you

[validatedev]

Thanks for reporting this! The application logs can be found at ~/Library/Logs/com.sunstory.openusage/OpenUsage.log. Could you enable the "Debug Level" setting by right-clicking the menu bar app, restart the app, and then check the logs to see what's happening with Claude? You can change the Debug Level after that.

[TytaniumDev]

Here you go! OpenUsage.log

[validatedev]

@TytaniumDev thanks! can you also check the usage by running claude in terminal and enter /usage? Can you able to see the usage in that way?

[TytaniumDev]

Woah good call, /usage doesn't work either. Attaching a screenshot, I'm obviously signed in with a subscription plan but it doesn't see it.

Hopefully just an issue on Claude's end then?

[validatedev]

I'd suggest logging out with /logout and then logging back in. Maybe it fixes the issue you are facing.

@agnuscloudgit is your issue the same as @TytaniumDev's or is it something different?

[TytaniumDev]

Thanks, the logout/login worked, and OpenUsage immediately started working again

[erik-lissen]

logout/login doesn't fix it for me :(

[2026-03-14][23:51:40][openusage_lib][INFO] probe batch 737d80a7-9a69-49fd-9cbe-ac06306a1dc8 starting: ["claude"]
[2026-03-14][23:51:40][openusage_lib::plugin_engine::host_api][WARN] [plugin:claude] keychain has data but no valid oauth
[2026-03-14][23:51:40][openusage_lib::plugin_engine::host_api][WARN] [plugin:claude] no credentials found
[2026-03-14][23:51:40][openusage_lib::plugin_engine::host_api][ERROR] [plugin:claude] probe failed: not logged in
[2026-03-14][23:51:40][openusage_lib][WARN] probe claude completed with error
[2026-03-14][23:51:40][openusage_lib][INFO] probe batch 737d80a7-9a69-49fd-9cbe-ac06306a1dc8 complete

killed all my sessions, logged out multiple times, restarted openusage, still just keeps saying not logged in

[erik-lissen]

I dug into this further and found the root cause.

The bug is in host_api.rs — the keychain read uses security find-generic-password -s "Claude Code-credentials" -w without specifying an account (-a flag).

The problem: Claude Code can create multiple keychain entries with the same service name Claude Code-credentials but different accounts. On my machine:

security dump-keychain | grep -A5 "Claude Code-credentials"

"acct" = "unknown"     ← only has mcpOAuth, no claudeAiOauth
"acct" = "CloudFlare"
"acct" = "e"           ← has claudeAiOauth.accessToken ✅
"acct" = "erik-lissen"

When you call security find-generic-password -s "Claude Code-credentials" -w without -a, macOS returns whichever entry it finds first — in my case "unknown", which has no OAuth token. That's why the log says keychain has data but no valid oauth.

Fix: iterate all matching accounts, or at minimum try the account matching the current OS username (-a "$USER"). The Rust code in host_api.rs should be something like:

// Try current OS user first, then fall back to iterating
let accounts = ["", &whoami::username()];
for account in accounts {
    let mut args = vec!["find-generic-password", "-s", &service, "-w"];
    if !account.is_empty() {
        args.insert(2, "-a");
        args.insert(3, account);
    }
    // ...try each until one has claudeAiOauth
}

Workaround (for anyone else hitting this): delete the stale "unknown" keychain entry so the default lookup finds the right one:

security delete-generic-password -s "Claude Code-credentials" -a "unknown"

(Claude wrote this, take it with a pinch of salt)

[validatedev]

@erik-lissen thank you for your through deep dive. i advise you to consider creating a pr for that issue if possible.

[dfurater]

I have the same issue. Logging in with Hide My Email feat. from Apple

[stovmascript]

Does OpenUsage work with an Anthropic Console account (API usage billing)?