Existing issues
What happened?
Clicking Add account under Providers → Claude → Claude Code accounts opens the browser, but the app always falls back to a red banner:
Claude sign-in did not complete. Try again and finish sign-in in your browser.
This happens whether or not the browser flow is completed, and the banner persists across app restarts. No account is ever added.
Expected: the account appears in the Claude Code accounts list.
This is not a credential problem. Reading the same account through OAuth works fine, so the account is valid and reachable. Only the Add account round-trip fails.
My setup may be relevant: Claude Code runs inside WSL2, and C:\Users\<user>\.claude is a directory symlink to \\wsl$\Ubuntu\home\<user>\.claude-personal. Reading through that symlink works. If the OAuth callback writes back to that path, it may be worth checking whether the write side handles the symlink differently from the read side. That is a guess, not a diagnosis.
Affected area
Steps to reproduce
- Open Settings → Providers → Claude
- Ensure
Allow reading Claude Code's credentials is enabled and Data source is oauth
- Click
Add account
- Complete the sign-in in the browser that opens
- Return to CodexBar - the red banner appears and no account is added
Logs, screenshots, or recordings
Working (read path):
> codexbar-cli.exe usage -p claude --source oauth
Claude (oauth)
Plan: Claude (default_claude_ai)
Session (5h): 47% used (resets in 2h 45m)
Weekly: 11% used (resets in 2d 14h)
Before enabling "Allow reading Claude Code's credentials":
OAuth: Reading Claude Code's credentials is off. Enable "Allow reading Claude Code's credentials" in Settings → Providers → Claude to use OAuth, or rely on Auto/CLI usage.
After enabling it, reads succeed but `Add account` still fails identically.
App version
v0.56.8
Windows version
Windows 11 25H2
Additional context
Paths below are anonymized. Both are real and the symlink resolves.
Claude Code runs inside WSL2 (Ubuntu), not natively on Windows. C:\Users<win-user>.claude is a directory symlink to \wsl$\Ubuntu\home<wsl-user>.claude-personal.
Reading through that symlink works. Usage refreshes fine, and if I repoint the symlink at a different profile directory and restart the app, it correctly reports the other account. So if the OAuth callback writes back to that path, maybe the write side handles the symlink differently than the read side. Just a guess.
No logs for the failure. I checked both files under %APPDATA%\CodexBar\logs\ right after a failed attempt:
- codexbar-desktop.log: only window/DWM events and shortcut registration, all INFO
- codexbar-cli.log: only ABE cookie warnings
Nothing about the OAuth flow in either. If there's a debug log level I can turn on, tell me and I'll re-run.
Cookie import isn't a fallback here either. Chrome App-Bound Encryption blocks it on every profile.
What I do instead: a PowerShell function that stops the app, repoints the .claude symlink, and relaunches. Usage and plan update correctly after that, which is more evidence that reading works and only sign-in is broken.
Existing issues
What happened?
Clicking
Add accountunder Providers → Claude →Claude Code accountsopens the browser, but the app always falls back to a red banner:This happens whether or not the browser flow is completed, and the banner persists across app restarts. No account is ever added.
Expected: the account appears in the
Claude Code accountslist.This is not a credential problem. Reading the same account through OAuth works fine, so the account is valid and reachable. Only the
Add accountround-trip fails.My setup may be relevant: Claude Code runs inside WSL2, and
C:\Users\<user>\.claudeis a directory symlink to\\wsl$\Ubuntu\home\<user>\.claude-personal. Reading through that symlink works. If the OAuth callback writes back to that path, it may be worth checking whether the write side handles the symlink differently from the read side. That is a guess, not a diagnosis.Affected area
Steps to reproduce
Allow reading Claude Code's credentialsis enabled and Data source isoauthAdd accountLogs, screenshots, or recordings
App version
v0.56.8
Windows version
Windows 11 25H2
Additional context
Paths below are anonymized. Both are real and the symlink resolves.
Claude Code runs inside WSL2 (Ubuntu), not natively on Windows. C:\Users<win-user>.claude is a directory symlink to \wsl$\Ubuntu\home<wsl-user>.claude-personal.
Reading through that symlink works. Usage refreshes fine, and if I repoint the symlink at a different profile directory and restart the app, it correctly reports the other account. So if the OAuth callback writes back to that path, maybe the write side handles the symlink differently than the read side. Just a guess.
No logs for the failure. I checked both files under %APPDATA%\CodexBar\logs\ right after a failed attempt:
Nothing about the OAuth flow in either. If there's a debug log level I can turn on, tell me and I'll re-run.
Cookie import isn't a fallback here either. Chrome App-Bound Encryption blocks it on every profile.
What I do instead: a PowerShell function that stops the app, repoints the .claude symlink, and relaunches. Usage and plan update correctly after that, which is more evidence that reading works and only sign-in is broken.