The Gemini provider uses Google's OpenAI-compatible endpoint
(generativelanguage.googleapis.com/v1beta/openai) but the client
routing condition in client.ts only checked CLAUDE_CODE_USE_OPENAI
and CLAUDE_CODE_USE_GITHUB — CLAUDE_CODE_USE_GEMINI was missing.
This caused every Gemini request to fall through to the Anthropic
client path. Since ANTHROPIC_API_KEY is not set when using Gemini,
the Anthropic SDK threw:
"Could not resolve authentication method. Expected either apiKey
or authToken to be set."
Fix: add CLAUDE_CODE_USE_GEMINI to the OpenAI shim routing condition
so Gemini requests correctly reach createOpenAIShimClient(), which
maps GEMINI_API_KEY → OPENAI_API_KEY and sets OPENAI_BASE_URL to
the Google endpoint.
Closes#176
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Previously getRateLimitResetDelayMs only read the Anthropic-specific
'anthropic-ratelimit-unified-reset' header (Unix timestamp), returning
null for every other provider. This meant OpenAI, GitHub, and Codex
users in persistent retry mode (CLAUDE_CODE_UNATTENDED_RETRY=1) always
fell back to dumb exponential backoff even when the server included an
exact reset time in the response headers.
This change makes the function provider-aware:
- firstParty (Anthropic): existing behaviour preserved — reads
'anthropic-ratelimit-unified-reset' Unix timestamp
- openai / codex / github: reads 'x-ratelimit-reset-requests' and
'x-ratelimit-reset-tokens' (OpenAI relative duration strings like
"1s", "6m0s", "1h30m0s"), picks the larger of the two so retries
don't fire before both token and request limits have reset
- bedrock / vertex / foundry / gemini: returns null (no standard
reset header for these providers)
Adds parseOpenAIDuration() as an exported helper to convert OpenAI's
duration format into milliseconds.
16 new tests covering all provider paths and edge cases.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
1. errors.ts: Add getCustomOffSwitchMessage() that returns a
provider-neutral message for 3P users instead of the hardcoded
"Opus is experiencing high load, please use /model to switch to
Sonnet" which is misleading for OpenAI/Gemini/Ollama users.
The original constant is preserved for backward-compatible string
matching in error handlers.
2. Onboarding.tsx: Skip the "approve API key" step when a 3P provider
is active. Previously, having ANTHROPIC_API_KEY in the environment
(e.g., from a previous Anthropic setup) triggered an irrelevant
Anthropic key approval UI even when using Gemini or OpenAI.
1. cli/update.ts: Block the update command for third-party providers.
The update mechanism downloads from Anthropic's GCS bucket, which
would silently replace the OpenClaude build (with the OpenAI shim)
with the upstream Claude Code binary (without it). Now shows an
actionable message directing users to rebuild from source.
2. codexShim.ts: Filter thinking blocks from assistant history, matching
the openaiShim behavior. Without this, thinking blocks were included
as plain text in assistant messages for the Codex transport but
excluded for the OpenAI transport — causing inconsistent history
when switching providers mid-session.
Three targeted fixes:
1. Replace Math.random() with crypto.randomUUID() for message and tool
call IDs in both openaiShim.ts and codexShim.ts. Math.random() is
not cryptographically secure and predictable in seeded environments.
2. Anchor Azure endpoint detection to parsed hostname instead of raw
URL regex. Adds support for Azure AI Foundry (services.ai.azure.com)
alongside existing cognitiveservices and openai Azure endpoints.
Prevents SSRF-style bypass via path segments.
3. Surface content safety filter blocks to the user. When Gemini or
Azure returns finish_reason 'content_filter' or 'safety', emit a
visible text block '[Content blocked by provider safety filter]'
instead of silently returning empty/truncated content with
stop_reason 'end_turn'. Applied to both streaming and non-streaming.
Two fixes for issue #133 where setting ANTHROPIC_API_KEY=dummy alongside
CLAUDE_CODE_USE_GEMINI=1 causes "Invalid API key" errors:
1. auth.ts: In the CI branch of getAnthropicApiKeyWithSource(), the
ANTHROPIC_API_KEY value was returned without checking isUsing3PServices().
A dummy key leaked into the Anthropic key resolution pipeline even when
Gemini was the active provider. Now guards with isUsing3PServices().
2. errors.ts: The x-api-key error handler surfaced "Invalid API key" for
any provider. Added getAPIProvider() === 'firstParty' guard so 3P users
see the real underlying error instead of a misleading auth message.
Note: The cli.tsx Gemini validation fix (originally part of this PR) was
independently implemented in PR #121 and is already on main.
OpenAI returns cached token counts in usage.prompt_tokens_details.cached_tokens
but the shim hardcoded cache_read_input_tokens to 0. This made prompt
caching invisible to the cost tracker and session summary even when
OpenAI's automatic caching was actively reducing costs.
Changes:
- Extend OpenAIStreamChunk usage interface with prompt_tokens_details
- Map cached_tokens to cache_read_input_tokens in convertChunkUsage()
- Same fix in _convertNonStreamingResponse() for non-streaming path
- cache_creation_input_tokens remains 0 (OpenAI auto-caching has no
creation cost — it is free and automatic)
Addresses the most critical remaining issues in the provider shim layer,
building on top of #124 (recursive schema normalization + try/finally).
openaiShim.ts:
- Throw APIError via SDK factory instead of plain Error — enables retry
on 429/503 (was completely broken: zero retries for all 3P providers)
- Guard stop_reason !== null before emitting usage-only message_delta
(Azure/Groq send usage before finish_reason)
- Fix assistant content: join text parts instead of invalid as-string cast
(Mistral rejects array content on assistant role)
- Expose real HTTP Response in withResponse() for header inspection
- Skip stream_options for local providers (Ollama < 0.5 compatibility)
codexShim.ts:
- Throw APIError at all 4 throw sites (HTTP + 3 streaming errors)
- Add tool_choice 'none' mapping (was silently ignored)
- Forward is_error flag with Error: prefix (matching openaiShim)
- Set competing provider flags to undefined in updateSettingsForSource to ensure clean GitHub boot
- Fix resolveProviderRequest to default to github:copilot when OPENAI_MODEL is unset
- Hydrate secure tokens and managed settings in system-check.ts to prevent false negatives
- Add models:read scope to GitHub device flow
Wait for failed MCP transport cleanup before command exit so targeted live checks do not crash on Windows.
Co-Authored-By: Claude <noreply@anthropic.com>
Add the diagnostics core and report model for MCP health, scope, and config analysis. This creates the structured report used by both text and JSON doctor output.
Co-Authored-By: Claude <noreply@anthropic.com>
- Make getProviderLabel() switch exhaustive with explicit openai/gemini
arms instead of falling through to env-var checks in default
- Add clarifying comment on additionalProperties override in schema
normalization
Partially addresses #112. The streaming reader in openaiStreamToAnthropic
had no error handling - if an error occurred during streaming, the reader
lock was never released. Wrapped the while loop in try/finally to ensure
reader.releaseLock() is always called.
Fixes#111. normalizeSchemaForOpenAI only processed the top-level
object schema, leaving nested objects untouched. OpenAI strict mode
rejects schemas where nested objects have properties not listed in
their required array, causing 400 errors on tools with nested params.
Now recurses into properties, items, and anyOf/oneOf/allOf combinators
(matching the pattern used by enforceStrictSchema in codexShim.ts).
Also adds additionalProperties: false to nested objects in strict mode.
Build verified passing.
- Introduced environment variable CLAUDE_CODE_USE_GITHUB to enable GitHub Models.
- Added checks for GITHUB_TOKEN or GH_TOKEN for authentication.
- Updated base URL handling to include GitHub Models default.
- Enhanced provider detection and error handling for GitHub Models.
- Updated relevant functions and components to accommodate the new provider.
Azure OpenAI API rejects the max_tokens parameter and requires
max_completion_tokens instead. This change ensures the conversion
is robust by validating that max_tokens is a positive number before
using it, preventing edge cases like null or "null" string values
from being incorrectly sent.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Two bugs in convertTools() caused Gemini's OpenAI-compatible endpoint
to reject tool schemas with 400 "schema requires unspecified property":
1. The Agent tool patch unconditionally pushed 'message' into required[]
even though 'message' is not a property of the Agent schema. Gemini
strictly validates that every key in required[] exists in properties.
2. normalizeSchemaForOpenAI() added all property keys to required[] for
OpenAI strict mode, but this conflicts with Gemini's stricter schema
validation which rejects required keys absent from properties.
Fix:
- Agent tool patch now only adds a key to required[] if it exists in
schema.properties (fixes the 'message' 400 error on Gemini)
- normalizeSchemaForOpenAI() accepts a strict flag: true for OpenAI
(promotes all property keys into required[]), false for Gemini
(filters required[] to only keys present in properties)
- convertTools() detects CLAUDE_CODE_USE_GEMINI and passes strict=false
Fixes#82
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Update the stale test expectation to match current behavior where
normalizeSchemaForOpenAI() promotes all properties into required[]
and marks the schema as strict: true.
Same fix as PR #72 — included here so PR #80 passes CI independently.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Azure OpenAI and newer OpenAI models (o1, o3, o4...) reject `max_tokens`
with a 400 error and require `max_completion_tokens` instead.
Maps `params.max_tokens` → `max_completion_tokens` in the request body,
which is the current standard across OpenAI-compatible providers.
