Codex SDK: allow embedded threads to use configured MCP/connectors

Feature request

Please add a supported way for @openai/codex-sdk callers to start or resume embedded Codex threads with configured MCP servers/connectors/tools, comparable to the connector/tool surfaces available in Codex Desktop sessions.

Use case

I am building a local-first personal agent app (Sugar) that embeds Codex SDK as the intelligence layer for user asks. The desired architecture is:

• route natural-language asks to Codex SDK;
• let Codex reason about the request;
• let Codex use configured tools/connectors such as Google Calendar when the user has authorized them;
• keep the host app responsible for context assembly, persistence, and UX, not deterministic semantic parsers for every integration.

Today, this breaks down for connector-backed tasks. In my Codex Desktop thread I can use the Google Calendar app connector to read events, create a temporary event, and delete it. But a nested @openai/codex-sdk thread launched by my app does not inherit that connector surface, and I do not see a documented SDK option to pass MCP servers/connectors/tools into startThread() / resumeThread().

The result is that host apps end up reimplementing deterministic integration layers or narrow provider calls instead of letting the Codex agent use the same tool model available in interactive Codex surfaces.

Current local evidence

Package: @openai/codex-sdk@0.134.0

The local SDK README documents thread options for working directory, sandbox, approval policy, web search, config overrides, env, images, and structured output. The local type definitions expose ThreadOptions fields such as:

• model
• sandboxMode
• workingDirectory
• networkAccessEnabled
• webSearchMode
• approvalPolicy
• additionalDirectories

But I do not see a documented/public option for attaching MCP servers, Codex app connectors, or connector authorization/session handles to a SDK thread.

Desired API shape

One or more of these would solve the problem:

1. A SDK-supported tools / mcpServers / connectors option on Codex or startThread() / resumeThread().
2. A way to pass through CLI config for MCP servers from the SDK without relying on undocumented config internals.
3. A way for embedded SDK sessions to use already-authorized Codex app connector sessions when the host environment has access.
4. Clear documentation of the recommended pattern for connector-capable embedded Codex agents.

Why this matters

Without this, embedded Codex apps are pushed toward duplicating integration-specific deterministic logic outside the agent. That is brittle: the host app starts parsing user intent and implementing narrow tool behavior, while the smarter agent is prevented from using the tools the user intended it to use.

For example, a user asks: read my calendar, create an event, and then delete it to make sure the calendar feature is working.

A Codex Desktop thread with Google Calendar tools can reason through that. An embedded SDK thread currently cannot unless the host app builds a separate calendar implementation and routes around the agent.

Expected behavior

A host app should be able to create a Codex SDK thread with explicit tool/connectors configuration, then ask the agent to perform a connector-backed task using those tools, subject to whatever authorization and sandbox rules are configured for that thread.

Additional context

This is not asking the SDK to silently bypass authorization. The host app should still explicitly configure or provide the tool/connector surface. The request is for a supported way to expose that surface to embedded SDK threads, so applications can keep semantic task handling inside Codex instead of recreating it with ad hoc deterministic layers.