OfflineCreator MCP compatibility with Codex
Connect the current Codex client without borrowing another client's config schema.
Run `codex mcp login offlinecreator` after the server entry exists. Codex documents OAuth login and logout only for Streamable HTTP servers that support OAuth. OfflineCreator's protected-resource metadata names `https://mcp.offlinecreatorstudio.com/mcp` as the resource and advertises `models`, `read`, and `generate` scopes. Its authorization-server metadata advertises dynamic client registration, authorization-code and refresh-token grants, public-client token authentication, and S256 PKCE.
Those published declarations describe the intended authorization boundary, but this pass did not run the Codex client or capture a current raw endpoint challenge receipt. It therefore does not prove that Codex registered, opened a browser, received a callback, stored a token, refreshed one, or accepted the server. If login stalls during a future acceptance test, preserve the exact Codex version and sanitized error before changing the endpoint or adding credentials.
- Login command
- codex mcp login offlinecreatorStart authorization only after the named server is present in Codex configuration.
- Expected server response
- OAuth browser flow after protected-resource discoveryA bare `401` is an authentication boundary, not proof that the endpoint is broken.
- Do not substitute
- Query-string keys or copied static headersThose bypass the recommended OAuth candidate and create a separate security and compatibility path.
Compatibility status: configuration and protocol verified, Codex acceptance pending
Current Codex documentation and OfflineCreator's current server declarations line up at the configuration boundary. Codex supports Streamable HTTP MCP servers in `config.toml`, uses stored MCP OAuth credentials by default, and provides a separate MCP login command. OfflineCreator publishes a Streamable HTTP endpoint and OAuth discovery metadata.
That alignment is enough to document a careful setup candidate, but it is not an end-to-end compatibility result. The Codex executable was not available in this research environment, so this pass did not parse the entry in a current client, complete browser authorization, inspect `/mcp`, or call an OfflineCreator tool. Keep this page support-qualified until those steps are reproduced in a dated Codex build.
- Documentation level
- Supported setup path identifiedCurrent first-party Codex documentation defines the required Streamable HTTP and OAuth controls.
- Protocol level
- OAuth metadata documentedThe published protected-resource and authorization-server documents identify the resource, scopes, and OAuth capabilities; no Codex authorization was attempted.
- Client acceptance level
- Not testedNo Codex OAuth completion, live tool listing, or OfflineCreator tool response was observed.
- OpenAI: Model Context Protocol
- OpenAI: Codex 0.147.0 release
- OfflineCreator Studio: MCP and CLI for AI image and video generation
- npm Registry / OfflineCreator Studio: @offlinecreator/mcp package README, version 0.1.2
- OfflineCreator Studio: OfflineCreator Studio MCP protected resource metadata
- OfflineCreator Studio: OfflineCreator Studio MCP authorization server metadata
Add OfflineCreator with Codex-owned configuration
Use Codex's own TOML schema rather than copying JSON from Cursor, VS Code, or another client. Codex stores user-level MCP configuration in `~/.codex/config.toml`; a trusted project can instead use `.codex/config.toml`. Add a table named `[mcp_servers.offlinecreator]` and set `url` to the exact OfflineCreator `/mcp` endpoint. OAuth is the default authentication fallback, so no bearer token or static authorization header belongs in this recommended entry.
The equivalent CLI path is `codex mcp add offlinecreator --url https://mcp.offlinecreatorstudio.com/mcp`. Current Codex documentation says the CLI and IDE extension share the same configuration, while project-scoped files load only for trusted projects. After adding the server, inspect the saved entry before authorizing; a different path, a missing `url`, or JSON-shaped keys such as `mcpServers` do not match the documented Codex schema.
- Recommended TOML
- [mcp_servers.offlinecreator] url = "https://mcp.offlinecreatorstudio.com/mcp" auth = "oauth"The explicit `auth` value documents intent; `oauth` is also Codex's default for an HTTP server.
- CLI alternative
- codex mcp add offlinecreator --url https://mcp.offlinecreatorstudio.com/mcpUse the client-owned command instead of adapting another host's configuration format.
- Credential rule
- No static key in the recommended entryLet the separate OAuth flow establish stored credentials.
Verify tools without spending generation credits
After browser authorization returns to Codex, start a fresh session and enter `/mcp`. Codex's current CLI reference says that command lists configured MCP tools, while `/mcp verbose` adds server diagnostics. Record three checkpoints separately: Codex loaded the configuration, OAuth completed, and OfflineCreator tools appeared. Passing one checkpoint does not establish the next.
The current OfflineCreator package documents nine tools and says visibility is filtered by authorization scope. Do not assume that every documented tool will appear for a particular grant. First confirm the actual names Codex exposes, then request `list_models` as a non-generation check. If tools are missing, compare the granted scopes and verbose diagnostics before retrying authorization; do not launch paid media generation merely to prove transport compatibility.
- Registry check
- /mcpConfirm that Codex exposes the server and its currently available tools.
- Diagnostic check
- /mcp verboseCapture server details without tokens, browser data, prompts, or account information.
- First non-spending tool
- list_modelsA catalog call is narrower evidence than a credit-consuming generation.
Page boundary
This page owns only the OfflineCreator setup candidate and acceptance boundary for Codex. It does not generalize Codex TOML to another client, treat matching OAuth declarations as completed interoperability, or promise successful authorization, token refresh, tool discovery, generation, account access, performance, reliability, adoption, or customer outcomes. Keep it as an unreviewed draft until a dated current-client acceptance run closes the documented gaps.