Signing in the vendor's way: one keychain slot per account

The end of pretending.

A Claude subscription is priced for use through Claude Code. For a while, some third-party tools used that subscription by making their own requests look like they came from Claude Code. VentureBeat described the technique in January 2026 as “spoofing the client identity, sending headers that convince the Anthropic server the request is coming from its own official command line interface (CLI) tool.”

The same report, on 9 January, said Anthropic had confirmed “strict new technical safeguards” against this, a move that disrupted users of the open-source agent OpenCode. The Hacker News thread, “Anthropic blocks third-party use of Claude Code subscriptions”, passed 600 points. In February, The Register reported that Anthropic had rewritten its legal page to make the rule explicit. Anthropic engineer Thariq Shihipar gave the reason in engineering terms: such tools “generate unusual traffic patterns without any of the usual telemetry that the Claude Code harness provides, making it really hard for us to help debug when they have questions about rate limit usage or account bans”.

We are not going to read terms of service for you, and this post makes no legal claim. The engineering lesson is simpler. Anything that fakes being the vendor's client is fragile: it breaks the day the vendor checks. The sturdy design is to let the vendor's own tool do the part that is the vendor's business, which is who you are and what your token is.

The real binary, in its own folder.

Luminair ships the Claude Code binary inside the app. When you click Add a Claude account, it does four things, all visible in desktop/engines/claude-cli.js:

Claude Code stores the credential itself, in the macOS login Keychain. The item is named Claude Code-credentials- plus the first eight hex characters of the SHA-256 of the folder path. Different folder, different name, different slot. That is Fig 01.

From then on, every turn on that account runs the same binary with the same folder. The usage meter asks the CLI for its numbers through a control request on its own channel. The engine file puts it bluntly: “We never read, copy, or refresh the credential; the CLI uses its own keychain slot for its own fetch.”

One slot holds one login.

Luminair did not start this way. The older sign-in, still in main.js as accounts:startLogin, ran the same CLI command without a private folder. The CLI wrote to the default slot, plain Claude Code-credentials. The app took a snapshot of that slot, waited for a new token to appear, and stored its own copy per account. Its own comment admits the limit: “The shared keychain holds one login at a time.”

That design has two weak points. The app holds copies of tokens it did not need to hold. And the whole thing depends on which folder the CLI thinks is home when it runs. Nobody expected that to change. It did.

An app that inherited a session.

Luminair is often updated from inside one of its own sessions. An update script stages the new build, and a small chain of helpers installs it and reopens the app: update-app.sh, then keep.sh, then install-staged-update.sh, then macOS open -a.

That session was running Claude Code for the Primary account, so its shell had CLAUDE_CONFIG_DIR set to the Primary account's folder, along with CLAUDECODE, CODEX_HOME and others. open passed that environment on. The relaunched app came up believing it lived inside Primary's folder.

Then an account was added through the old path. It spawned claude auth login with the app's full environment, so the CLI ran inside Primary's folder. The browser signed into a Team workspace, and the CLI saved that credential into Primary's slot, as it should for that folder. Meanwhile the app was watching the shared slot, so as far as it could tell the sign-in never connected.

The next turn on Primary failed with “Your organization has disabled Claude subscription access”. The account had not been banned. It had been swapped for a different workspace. The same day, a second existing account was overwritten the same way.

Belt, braces, and a clean reopen.

The fix, in commit 5fc52f1c, closes the leak three times over, so no single miss can reopen it.

First, scrub at startup. A new module, inherited-env.js, lists every variable that only makes sense inside one session or one helper job. It runs at the very top of main.js, before any process is spawned, and deletes those keys from the app's own environment. What it removed is written to the security log as app.inherited-session-env.

const EXACT = new Set([
  'CLAUDE_CONFIG_DIR',        // per-account sign-in folder of a running session
  'CLAUDECODE',               // "you are inside a Claude Code session" marker
  'CLAUDE_PID',
  'CLAUDE_AGENT_SDK_VERSION',
  'CLAUDE_CODE_OAUTH_TOKEN',  // a session's inference token
  'CODEX_HOME',               // per-account sign-in folder of a Codex session
  'CODEX_CI',
  'CODEX_THREAD_ID',
  'CODEX_SESSION_ID',
]);
const PREFIXES = ['CLAUDE_CODE_', 'OW_KEEP_', 'OW_MCP_'];

Second, a clean environment for every login. Both sign-in paths now spawn the CLI with a filtered copy, so they do not depend on the scrub having run. The per-account path also drops ANTHROPIC_API_KEY, ANTHROPIC_BASE_URL and the Bedrock, Vertex and Foundry switches before setting its own folder, so a stray API key in your shell cannot quietly take over a subscription account.

Third, reopen with nothing. The installer now reopens the app under env -i, passing only HOME, USER, LOGNAME and a minimal PATH.

The same afternoon, a separate commit, de0c2ee5, removed the old path from the front door. Add a Claude account and both re-login entry points now go through the per-account login. The legacy flow is kept only for old token accounts that still need it.

An email is not an identity.

The overwrite had a second lesson. A personal account and a Team workspace can share one email address. Luminair used to de-duplicate accounts by email alone, so adding a Team workspace looked like adding a twin of the personal one, and it was dropped. Since 14 September an account's identity is its email plus its organization, both read from the CLI, and a Team account carries a Team badge and its organization's name.

With that, the per-account login checks the result before it keeps anything:

That last clean-up came a day later. On 15 September we found that removing a folder left its Keychain item behind: a dozen orphaned credentials had piled up from failed and removed sign-ins. Removing or failing a Claude sign-in now also runs security delete-generic-password on the matching slot. The same commit fixed a sign-in that timed out every time: the bundled CLI was waiting for the browser's code, and nothing was handing it back.

Add an account, safely.

1. 1Open Settings › Connectors, choose Claude, then Add a Claude account. Your browser opens on Anthropic's sign-in page.
2. 2Approve, then press Copy on the code page. Luminair picks the code up from the clipboard and says so; you can also paste it into the box yourself.
3. 3If you use a personal account and a Team workspace on one email, add each one. They show as separate accounts, the Team one with its badge and organization name.

Removing an account deletes its folder and its Keychain item together. The app only ever removes folders inside its own data directory.

Checked, and not claimed.

Sources

• VentureBeat · 9 January 2026Anthropic cracks down on unauthorized Claude usage by third-party harnesses and rivals
• Hacker News · 9 January 2026Anthropic blocks third-party use of Claude Code subscriptions
• The Register · 20 February 2026Anthropic: No, absolutely not, you may not use third-party harnesses with Claude subs