model-benchmark: claude adapter `available()` reports "No Claude auth found" for macOS subscription installs (claude -p works)

[chrono-meta]

Observed problem

test/helpers/providers/claude.ts ClaudeAdapter.available() treats Claude auth as present only when ~/.claude/.credentials.json exists or ANTHROPIC_API_KEY is set:

const credsPath = path.join(os.homedir(), '.claude', '.credentials.json');
const hasCreds = fs.existsSync(credsPath);
const hasKey = !!process.env.ANTHROPIC_API_KEY;
if (!hasCreds && !hasKey) {
  return { ok: false, reason: 'No Claude auth found. Log in via `claude` interactive session, or export ANTHROPIC_API_KEY.' };
}

On a macOS subscription install (the default Claude Code install on Mac), ~/.claude/.credentials.json is absent — the credential lives elsewhere (likely the Keychain) — yet the subscription session authenticates claude -p fine. So the file-existence check is a proxy that misses a valid auth state, and the adapter reports NOT READY for a provider whose run() path (claude -p --output-format json) would actually succeed.

This is internal to the adapter: run() uses the subscription via claude -p, so available() rejecting that same auth state is an inconsistency, not a user-config gap. (ANTHROPIC_API_KEY is a workaround, but macOS subscription users have no key and don't need one for claude -p.)

Current behavior on main (cab774c)

$ gstack-model-benchmark --dry-run --prompt "hi"
  claude: NOT READY — No Claude auth found. Log in via `claude` interactive session, or export ANTHROPIC_API_KEY.

On the same machine:

• ~/.claude/.credentials.json — absent
• claude CLI — resolves (claude --version → 2.1.x), logged in via subscription; claude -p works
• available() returns {ok:false} purely on the missing file

Any code path gated on this available() (model-benchmark, and the LLM-judge path) silently drops the claude provider for this population.

Expected behavior

A logged-in macOS subscription install (no ANTHROPIC_API_KEY, no .credentials.json, but claude -p working) should report the claude adapter as available.

Possible fix

run() already classifies runtime auth failures gracefully (/unauthorized|auth|login/i → auth). So available() could be optimistic when resolveClaudeCommand() resolves on macOS (defer the real auth decision to run()), or detect the Keychain credential — whichever you prefer.

Duplicate search performed

• Issue search (model-benchmark auth, No Claude auth, credentials.json, ANTHROPIC_API_KEY subscription, claude adapter available): no existing issue.
• Open PRs touching the adapter / benchmark provider: fix(benchmark): validate timeout flag #1727 (benchmark timeout flag), feat: add OllamaAdapter for local-inference benchmarking #1495 (OllamaAdapter), feat(design): add provider abstraction with Gemini support #998 (provider abstraction / Gemini) — none touch claude.ts available() auth detection. No collision.

[carter-smalls]

This reads like auth/config trouble with Anthropic. npx ai-doctor can spot API key issues and auth config problems.

[chrono-meta]

Thanks — to clarify, this isn't user-side auth: claude -p authenticates fine on this machine (subscription, no key). The report is that available() rejects that working state because it only file-checks .credentials.json, while run() uses the same auth successfully. So it's an internal available()/run() inconsistency, not a config gap — ai-doctor wouldn't apply since there's no broken key to find.

[jbetala7]

Opened #1894 with the fix: keep the creds-file / ANTHROPIC_API_KEY fast-path, but on macOS defer the auth decision to run() (which already classifies a logged-out state as an auth error) instead of treating an absent ~/.claude/.credentials.json as proof of no auth. Non-macOS keeps the strict file/key check. Adds a regression test covering the macOS subscription case (fails on main, passes with the fix).