Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Claude: sign in with claude.ai inside CodexBar when Claude Code is not installed

Open
  • Is something wrong?
#4,827 1 comment 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
43/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
swift
Domain
authentication, desktop

Research direction

Start by reading the Claude cookie configuration and recovery guidance in docs/claude.md, then trace the existing manual cookie setting used by codexbar config set-cookie. The proposal describes a macOS WKWebView sign-in flow, cookie storage, expiry handling, and refresh behavior; check how those pieces fit the app's current authentication and usage refresh paths. Done means a user can sign in without Claude Code and see usage, with expired sessions prompting sign-in again.

Written by the indexing model from the issue text.

Description

clawsweeper:needs-product-decision clawsweeper:needs-security-review clawsweeper:no-new-fix-pr clawsweeper:source-repro impact:auth-provider impact:ux-release-blocker issue-rating: 🦞 diamond lobster P0

Problem

Claude usage needs one of three sources: Claude Code's OAuth login, the Claude Code CLI, or browser cookies. The built-in "Claude login" runs claude auth login --claudeai, so it requires Claude Code to be installed.

Users who only use claude.ai in a browser have no simple path:

  • Browser cookie import fails for some browsers and setups (for example Firefox profiles, Safe Storage Keychain prompts, or the wrong browser profile).
  • The fix today is the manual recovery steps in docs/claude.md or installing and signing in to Claude Code. That is hard for non-developers.

Proposal

Add an optional "Sign in with claude.ai" window:

  1. Open a small WKWebView on https://claude.ai/login with a non-persistent data store (nothing shared with Safari).
  2. After sign-in, read the sessionKey cookie from that store.
  3. Save it as a manual cookie for Claude (the same result as codexbar config set-cookie), close the window, clear its data and refresh.
  4. When the session expires (401/403), show "Sign in" again instead of silently falling back to another source.

What we learned from a prototype

We built this in a downstream app on top of CodexBar's manual cookie setting (cookieSource: "manual" + cookieHeader) and tested it on macOS:

  • Sign-in on claude.ai worked inside WKWebView (no Cloudflare loop).
  • The window closed and usage appeared within a minute; values matched claude.ai/settings/usage.
  • Limits: password autofill does not work in the embedded window (claude.ai does not allow third-party apps for associated domains), and Google sign-in may be blocked in embedded web views by Google's policy, so e-mail code sign-in is the reliable path.

Happy to share more details if this direction fits CodexBar.

Dominant language
Swift
Stars
22.8k
Forks
2.2k
Avg merge
21h 49m
Merged PRs (30d)
368

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from steipete/CodexBar

All issues in steipete/CodexBar

Similar issues

More Swift issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.