AsyncOpenAI(api_key="") raises OpenAIError in v2.34.0, breaking OpenAI-compatible local servers

Confirm this is an issue with the Python library and not an underlying OpenAI API

This is an issue with the Python library

Describe the bug

In v2.34.0, AsyncOpenAI(api_key="") now raises OpenAIError: Missing credentials. In v2.33.0 and earlier, passing an empty string was silently accepted.

This is a breaking change for anyone using the OpenAI Python SDK to talk to OpenAI-compatible local servers (llama.cpp, llamafile, LM Studio, vLLM, etc.) that do not require authentication. These wrappers intentionally pass api_key="" because no credentials are needed for a local HTTP server.

The root cause appears to be the new credential validation logic in _client.py around line 700, which now checks not self.api_key (falsy for ""), along with the new workload_identity and admin_api_key checks added in 2.34.0.

Previous behavior (v2.33.0): AsyncOpenAI(api_key="", base_url="http://localhost:8080/v1") succeeded and produced a usable client.

New behavior (v2.34.0): The same call raises:

openai.OpenAIError: Missing credentials. Please pass an `api_key`, `workload_identity`,
`admin_api_key`, or set the `OPENAI_API_KEY` or `OPENAI_ADMIN_KEY` environment variable.

The workaround is to pass a non-empty placeholder string (e.g., api_key="not-needed"), but this is surprising since api_key="" worked in all prior versions.

To Reproduce

Install openai==2.34.0
Run the code below
Observe OpenAIError raised

Code snippets

from openai import AsyncOpenAI

# Works in 2.33.0, fails in 2.34.0
client = AsyncOpenAI(
    api_key="",
    base_url="http://localhost:8080/v1",
)

OS

Linux and macOS (all platforms)

Python version

Python 3.11, 3.12, 3.13

Library version

openai v2.34.0

+1 for this. Tests and other CI are failing because of hard requirement.

fix: allow api_key="" to bypass credential validation for local servers

Hey, I'd like to hop in on this. I see PR #3225 from the issue author is already open.

My approach: capture whether api_key was explicitly provided by the caller before the env var fallback. A flag _api_key_explicitly_provided = api_key is not None is set right before os.environ.get('OPENAI_API_KEY') in both OpenAI.__init__() and AsyncOpenAI.__init__(). The credentials check then becomes:

if (
    _enforce_credentials
    and not self.api_key
    and not _api_key_explicitly_provided   # <-- skip error if caller passed api_key=""
    and self._api_key_provider is None
    and workload_identity is None
    and self.admin_api_key is None
):

This way passing api_key="" (explicit intent, local servers) is allowed, while omitting api_key entirely with no env var still raises. Also initialising the flag to False before the workload_identity branch keeps it safe regardless of path taken. Happy to open a PR with tests if this direction works for the maintainers.

fix: allow api_key="" to bypass credential validation for local servers

Use openai < 2.34.0

fix: allow api_key="" to bypass credential validation for local servers

Working on this in PR #3630.

Thanks for reporting this, and sorry for the disruption to existing integrations. We’re keeping the empty-key check to catch missing credentials early. For local servers that don’t require authentication, please pass an explicit placeholder such as api_key="not-needed" alongside your local base_url.

Navigation Menu

Repository navigation

AsyncOpenAI(api_key="") raises OpenAIError in v2.34.0, breaking OpenAI-compatible local servers #3224

Confirm this is an issue with the Python library and not an underlying OpenAI API

Describe the bug

To Reproduce

Code snippets

OS

Python version

Library version

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

AsyncOpenAI(api_key="") raises OpenAIError in v2.34.0, breaking OpenAI-compatible local servers #3224

Description

Confirm this is an issue with the Python library and not an underlying OpenAI API

Describe the bug

To Reproduce

Code snippets

OS

Python version

Library version

Activity

bheemaguli commented on May 12, 2026

SanskaarUndale21 commented on May 19, 2026

Xsidz commented on Aug 16, 2026

marcuswood-oai commented on Sep 10, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions