Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- The official changelog records deprecation on August 24, 2026 and removal on September 5, 2026. This is migration from an existing retired interface, not a new launch on October 11, 2026.
- The removed entry points hosted Codex itself as an MCP server. External MCP tools and the codex mcp management command remain supported.
- App Server is not a drop-in replacement for an MCP client: initialization, threads and turns, event streaming and approval responses need adaptation.
- The App Server command remains experimental and is not supported for production workloads. Review commercial authentication restrictions and remote-listener security first.
The old entry points are gone: identify both launcher names before upgrading
The current official migration page explicitly says the codex mcp-server command and standalone codex-mcp-server binary have been removed. Integrations launching either must migrate before upgrading. The old MCP tool reference and Agents SDK examples are no longer supported as current integration instructions.
The changelog records deprecation on August 24, 2026 and the removal announcement on September 5, 2026. These notices do not name the exact first CLI version containing removal, nor establish that every older installation has been remotely disabled.
Look for both names in editor configuration, service launchers and automation scripts, then record the installed version, arguments and exact error. Seeing MCP in a configuration is not enough to identify this issue. A failed connection alone does not prove an account, plan or regional block.
External MCP tools remain supported: identify what actually needs migration
The old entry points exposed Codex to an external MCP client. In contrast, codex mcp manages the external MCP servers that Codex connects to, and OpenAI explicitly says those remain supported. If a database, search service or another downstream tool fails to start, investigate that tool rather than deleting every MCP connection.
App Server serves integrations needing authentication, conversation history, approvals and streamed agent events through its own JSON-RPC protocol. It is not a standard MCP server or a direct replacement for an ordinary MCP client. A host that only sends MCP tool calls needs a different integration layer.
For example, suppose an IDE previously launched codex mcp-server as a tool process. Replacing that command with codex app-server will not turn the old MCP handshake into a valid request. This hypothetical example illustrates the protocol boundary; the IDE's actual client capabilities determine whether migration works.
Connecting a custom client: initialize before starting a thread
The documented default is stdio, with one JSON message per line. App Server uses bidirectional JSON-RPC 2.0 but omits the jsonrpc field on the wire. Do not reuse the old MCP request shape or assume that a running process proves the connection is ready.
On each connection, send initialize followed by the initialized notification before calling thread/start or thread/resume and turn/start. Requests before initialization receive Not initialized; repeated initialization receives Already initialized. Handle this as part of the connection lifecycle.
Save the thread identifier and keep consuming notifications. Generate matching types or schemas with your installed version's generate-ts or generate-json-schema commands; the output corresponds to the CLI version that generated it. For job automation or CI, OpenAI separately recommends the Codex SDK.
More than a tool response: handle approvals and final states
After starting or resuming a thread, keep processing thread, turn and item events. A turn/completed event can carry completed, interrupted or failed. Receiving a terminal event does not establish success, and successful execution does not mean the output passed your own quality checks.
Command execution and file changes may require approval. The server initiates a JSON-RPC request; the client must present it in the correct thread and turn, respond with a decision, then handle serverRequest/resolved and item/completed. An unanswered approval is not simply a network stall, and approvals must not default to allowing everything.
Preserve error messages and status. When an upstream HTTP status is available, the documentation says it appears in the relevant error information. Use backoff and jitter for the -32001 overload error rather than retrying every failure indefinitely. Show interruption, authentication failure and permission denial as distinct outcomes.
Before offering it to users: experimental, authentication and listener limits
OpenAI currently labels the App Server command and WebSocket transport experimental and unsupported for production workloads. The migration recommendation does not promise a stable commercial interface or identical model access across plans, regions and accounts. Check the actual available model list and access conditions.
The authentication documentation permits existing local or open-source applications to continue using App Server authentication, but explicitly says that authentication has never been permitted for commercial or hosted services. Commercial use is directed to Sign in with ChatGPT and its own eligibility rules; this page does not grant commercial authorization or free usage.
Protect remote listeners separately. The current documentation warns that non-loopback listeners are unauthenticated by default during rollout, so configure authentication explicitly and use TLS. Plain ws is for localhost or SSH forwarding. Do not expose an unauthenticated port for troubleshooting or put a token directly in command-line arguments.
Checking and reverting the change: keep a known version and a controlled fallback
Keep a copy of the launcher configuration, a verified version and an owner for the change. Record only nonsensitive arguments and log timestamps. In an isolated project without sensitive data, check initialization, a new thread, resumption, approval and denial, interruption, failure states and exit behavior; confirm that the working directory and permissions have not expanded.
Stop expanding the rollout if threads cannot resume, approvals have no usable interface, errors disappear or child processes do not exit. Returning to a verified environment restores a controlled workflow; it does not guarantee long-term availability of the old entry points. Whether an old installation still has the command depends on that version's actual behavior.
After switching, monitor thread resumption, pending approvals and process cleanup, and compare the CLI version with the current protocol. Investigate DNS, TLS, proxy authentication and transport blocking separately. A healthy network will neither convert MCP requests into the App Server protocol nor remove authentication-use restrictions.
Sources
Frequently Asked Questions
Is the old command deprecated, or has it actually been removed?
OpenAI now explicitly says codex mcp-server and standalone codex-mcp-server have been removed. The changelog records deprecation on August 24 and removal on September 5. These notices do not identify the exact first CLI version containing the removal.
Can Codex still connect to MCP tools?
Yes. OpenAI explicitly says external MCP servers remain supported and codex mcp still manages those connections. Removal concerns the old entry points that hosted Codex itself as an MCP server.
Can I reuse an old Claude Code or Agents SDK MCP configuration unchanged?
Do not treat the old MCP tool reference or Agents SDK examples as a supported solution. Check the caller's current integration options. A client connecting to App Server must implement its independent protocol rather than merely changing the launcher command.
Why does my first request fail after App Server starts?
Check that initialize and initialized completed on the same connection before sending thread or turn requests. Requests before initialization return Not initialized; repeated initialization returns Already initialized. Then investigate the exact error, message shape, authentication and permissions.
If an older version still has the command, can I keep using it indefinitely?
No such assurance follows. An old installation's behavior is not a current support commitment; OpenAI says the old entry points and examples are unsupported. A verified environment can provide a controlled fallback, but plan migration rather than promising long-term availability of that version.
Does a working local connection let me offer a commercial service?
That conclusion is not supported. App Server is experimental and unsupported for production workloads, and its existing authentication is not permitted for commercial or hosted services. Confirm listener authentication, TLS, model access and the appropriate integration eligibility separately.