v2.43.0: tunnel_id and Reaching OpenAI From Firewalled Infrastructure
The headline addition in openai v2.43.0 is tunnel_id, a third way to wire up an MCP tool. Published on June 17, 2026 , the release is a 2-commit, 14-changed-file diff — mostly version metadata plus generated type changes across the Responses and Realtime MCP tool shapes . tunnel_id is the one substantive change.
It joins server_url and connector_id as configuration options, and the type contract is strict: exactly one of the three must be provided, never a combination .
| Field | Points at |
|---|---|
server_url | An arbitrary public remote MCP server |
connector_id | An OpenAI-maintained connector (e.g. Google Workspace, Dropbox) |
tunnel_id | A Secure MCP Tunnel to a private, non-public server |
The mechanism is what makes this useful. A tunnel-client opens outbound HTTPS to OpenAI, long-polls for JSON-RPC work, executes each request locally, and returns results back through the tunnel . The server itself never needs an inbound port or a public endpoint — connectivity is initiated entirely from your side.
That opens a concrete set of targets that previously couldn't sit behind the Responses API, ChatGPT, or Codex:
- Developer machines running a local MCP server during testing
- On-prem servers inside a corporate network
- Firewalled infrastructure with no route to the public internet
- Any MCP server that should not — for security or policy reasons — expose a public URL
Spend Alerts, Expiry, and Audit Filtering in v2.42.0
One release earlier, v2.42.0 was the heavier diff of the two: 8 commits and 26 changed files, against v2.43.0's two commits and 14 files. The headline addition is spend_alerts, a programmatic Admin API resource for budget management. It exposes full CRUD — create, retrieve, update, list, delete — at both the organization level (/organization/spend_alerts) and the project level (/organization/projects/{project_id}/spend_alerts), and it requires admin API key auth [ref].
The two scopes return distinct objects: organization.spend_alert for org-wide budgets and project.spend_alert for per-project ones. The alert shape is narrow and worth reading before you wire it up:
| Field | Value / constraint |
|---|---|
currency | USD |
interval | month |
threshold_amount | integer in cents, minimum 0 |
notification_channel | email recipients list + optional subject prefix |
The cents-based threshold_amount is the easy thing to get wrong — a $50 budget is 5000, not 50 [ref].
v2.42.0 also tightened key and audit governance. Admin API key creation gained expires_in_seconds, and the key model now carries expires_at, so short-lived admin credentials can be issued in code instead of living indefinitely. Audit-log filtering added a tenant_only flag plus two tenant-scoped role events — role.bound_to_resource and role.unbound_from_resource — which surface ChatGPT workspace connector resource IDs formatted as <workspace_id>__<connector_id> [ref].
The throughline: none of this touches ordinary model calls. v2.42.0 is platform-admin and governance surface — the kind of plumbing teams managing org-level spend and access will care about, and the kind everyone else can skip [ref].
The Prior Sprint: Moderation on Responses and Chat Completions
Step back two weeks and the same additive pattern holds. v2.41.0, released June 3, 2026, surfaced inline content moderation on two surfaces at once — responses.moderation and chat_completions.moderation . The payoff for builders is one fewer round trip: the moderation object comes back alongside the completion, so you no longer fire a separate Moderation API call to screen the same text.
Two days earlier, v2.40.0 (June 1, 2026) added Amazon Bedrock Responses support and a fix letting Bedrock API keys be set directly on the client object — removing a prior environment-variable-only workaround for AWS users .
Read in sequence, the June sprint is not iterating on a single API shape. Each minor bolts on a distinct layer:
- v2.40.0 — cloud-provider reach (Bedrock Responses)
- v2.41.0 — inline moderation on Responses and Chat Completions
- v2.42.0 — admin governance (spend alerts, key expiry, audit filtering)
- v2.43.0 — private-network connectivity via
tunnel_id
Four releases, four separate concerns — which is exactly what you'd expect when the SDK is tracking upstream schema additions rather than reworking one feature.
How Spec Drift Drives the Release Cadence
The reason four releases cover four unrelated concerns is mechanical: the SDK is code-generated. Each release commit carries the same changelog line — update OpenAPI spec or Stainless config — because Stainless regenerates the openai package directly from OpenAI's OpenAPI specification . Any delta in that upstream spec, or in the Stainless generator config, triggers a fresh release without a human authoring feature code.
That automation explains the tempo. Through June 17, 2026, the visible history shows five minor releases in the month: v2.39.0 and v2.40.0 on June 1, v2.41.0 on June 3, v2.42.0 on June 16, and v2.43.0 on June 17, plus patch v2.41.1 . Two minors landing on consecutive days is not a coincidence — it is what spec-push automation produces.
"update OpenAPI spec or Stainless config" — the recurring release line in the openai-python CHANGELOG.
The pipeline itself was tuned mid-sprint. v2.41.1 "removed scheduled release workflow trigger" and v2.42.0 "fixed release workflow permissions" — the team retired the last manual schedule knob so spec changes flow straight to publish.
The cost of that terseness: "update OpenAPI spec" hides the actual server-side change behind each diff, which is not always documented publicly. For real signal, read the GitHub compare view rather than the tag note — the v2.42.0...v2.43.0 delta shows just two commits and 14 changed files , telling you far more than the changelog line ever will.
Considering Your Version Constraints
Every release from v2.40 through v2.43 is a SemVer minor, which means the additions are intended to be backward-compatible — no documented breaking changes across that span . New type shapes like tunnel_id, spend_alerts, and Responses moderation widen the surface without removing existing fields, so upgrades within 2.x should be additive for most callers.
The cost is churn. Five minors landed in 21 days — June 1 through June 17, 2026 — roughly one merge request per week if you let Dependabot or Renovate track latest . Teams pinning exact versions (openai==2.42.0) will see a steady stream of bump PRs that the terse update OpenAPI spec tag does little to triage.
A practical posture:
- Pin to a compatible minor range:
openai>=2.40,<3. - On each bump, open the GitHub compare diff — the v2.42.0...v2.43.0 delta shows two commits and 14 changed files .
- Grep the generated type files for new fields before assuming parity.
The takeaway: treat the changelog tag as a pointer, not a summary — the compare view is where the real signal lives.
Frequently asked questions
What is tunnel_id and how does it differ from server_url for MCP tool configuration?
tunnel_id is a field added to the Responses and Realtime MCP tool shapes in openai-python v2.43.0 . It routes MCP calls through OpenAI's Secure MCP Tunnel: a local tunnel-client opens outbound HTTPS to OpenAI and long-polls for work, so the MCP server needs no public endpoint . By contrast, server_url points at a reachable public server, and connector_id targets an OpenAI-maintained connector wrapper (Google Workspace, Dropbox, and similar) . The type contract requires exactly one of the three.
Can I create and manage OpenAI spend alerts programmatically as of v2.42.0?
Yes. v2.42.0 added an admin spend_alerts resource exposing create, retrieve, update, list, and delete methods . Endpoints exist at both organization level (/organization/spend_alerts) and project level (/organization/projects/{project_id}/spend_alerts) . Alerts use currency: USD, interval: month, a threshold_amount in cents (minimum 0), and an email notification_channel. Note the auth requirement: these calls need an admin API key, not a standard user key.
Why does the openai-python SDK release so frequently with terse changelog entries?
The SDK is code-generated by Stainless from OpenAI's OpenAPI specification, so any upstream spec push triggers an automated release commit rather than hand-authored feature work . That is why the recurring changelog line reads only update OpenAPI spec or Stainless config, and why five minor releases landed in June 2026 alone . The team also removed the scheduled release workflow trigger in v2.41.1, so versions now fire directly on spec-change events — even a small schema delta produces a fresh minor.
Is upgrading from v2.40 to v2.43 safe without a migration guide?
Likely yes. These are SemVer-minor, Stainless-generated additions within 2.x, intended to be additive and backward-compatible, and no breaking changes are documented . The main caveat is for code that imports generated types directly: new optional fields such as tunnel_id and expires_in_seconds can affect strict type assertions. Before assuming parity, open the GitHub compare diff — the v2.42.0...v2.43.0 delta is two commits and 14 changed files . Grep the changed type files for new fields, then upgrade.
