Skip to content

feat: support OPENAI_BASE_URL for the openai provider#328

Open
Echo (Pahkho) wants to merge 1 commit into
langchain-ai:mainfrom
Pahkho:feat/openai-base-url-from-env
Open

feat: support OPENAI_BASE_URL for the openai provider#328
Echo (Pahkho) wants to merge 1 commit into
langchain-ai:mainfrom
Pahkho:feat/openai-base-url-from-env

Conversation

@Pahkho

Copy link
Copy Markdown

Summary

The openai provider had no baseUrlEnvKey, so a custom base URL could only reach it implicitly (relying on the OpenAI SDK to read process.env.OPENAI_BASE_URL). It was not loaded from ~/.openwiki/.env into the OpenWiki-managed environment, never surfaced in credential diagnostics, and never flowed through resolveProviderBaseUrl like the openai-compatible and anthropic providers do.

Changes

  • src/constants.ts: add OPENAI_BASE_URL_ENV_KEY and set it as the openai provider's baseUrlEnvKey. resolveProviderBaseUrl("openai") now honors OPENAI_BASE_URL, and the resolved value is passed to the model client via configuration.baseURL (no behavior change when unset — still falls back to the SDK default).
  • src/env.ts: register OPENAI_BASE_URL in MANAGED_ENV_KEYS so it is loaded from ~/.openwiki/.env, persisted in stable order, and shown (non-secret) in credential diagnostics alongside ANTHROPIC_BASE_URL / OPENAI_COMPATIBLE_BASE_URL.
  • README.md: document OPENAI_BASE_URL for the openai provider under "Alternative base URLs".

Why

Some OpenAI-compatible gateways only expose the Responses API (/v1/responses) and return 502 for chat-completions requests that carry tools. The openai provider already routes tool calls through the Responses API (useResponsesApi: provider === "openai"), so it works against such gateways — but only if the base URL can be configured. With this change, users can target a Responses-API gateway directly from .env:

OPENWIKI_PROVIDER=openai
OPENAI_API_KEY=your-key
OPENAI_BASE_URL=https://your-gateway.example.com/v1
OPENWIKI_MODEL_ID=your-model-name

Previously the only .env-configurable path was openai-compatible, which routes tool calls through chat completions and fails with 502 on these gateways.

Notes

  • OPENAI_BASE_URL was already removed from deprecatedEnvKeys on main, so it is already loaded from .env into process.env. This PR makes the openai provider consume it explicitly and consistently rather than relying on the SDK's implicit env-var read.
  • No change when OPENAI_BASE_URL is unset; requiresBaseUrl is not set, so the provider remains optional-default.

🤖 Generated with Claude Code

The `openai` provider had no `baseUrlEnvKey`, so a custom base URL could
only reach it implicitly via the OpenAI SDK reading the `OPENAI_BASE_URL`
env var. Make this explicit and consistent with the `openai-compatible`
and `anthropic` providers:

- Add `OPENAI_BASE_URL_ENV_KEY` and wire it as the `openai` provider's
  `baseUrlEnvKey`, so `resolveProviderBaseUrl("openai")` honors it and the
  resolved `baseURL` is passed through to the model client.
- Register `OPENAI_BASE_URL` in `MANAGED_ENV_KEYS` so it is loaded from
  `~/.openwiki/.env`, persisted in stable order, and surfaced in the
  credential diagnostics as a non-secret value (like the other base URL keys).

This lets the `openai` provider target an OpenAI-compatible Responses-API
gateway (e.g. a Codex-backed proxy) directly from `.env`, instead of forcing
users onto the `openai-compatible` provider, which routes tool calls through
chat completions and fails on such gateways.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@Pahkho
Echo (Pahkho) force-pushed the feat/openai-base-url-from-env branch from 55326f1 to 1f07d86 Compare July 16, 2026 01:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants