codex_apps MCP fails to initialize on Turkey network route with error decoding response body; succeeds from alternate US network egress

What version of Codex CLI is running?

v0.125.0

What subscription do you have?

Business

Which model were you using?

gpt-5.5 xhigh

What platform is your computer?

Linux 6.17.0-PRoot-Distro Ubuntu aarch64 aarch64

What terminal emulator and version are you using (if applicable)?

Termux

What issue are you seeing?

Problem

When starting Codex through a Turkey network route, the codex_apps MCP client fails to initialize.

Startup shows:
~~~text
MCP client for codex_apps failed to start:
MCP startup failed: Transport send error:
HTTP request failed: error decoding response body
~~~

The /mcp command may still list GitHub tools, but this appears to be cached/startup tool metadata rather than a working live MCP client.

A real GitHub MCP tool call fails:

~~~text
github_get_user_login
-> failed to get client
-> MCP startup failed
-> HTTP request failed: error decoding response body
~~~

Important distinction

This is not token_invalidated.
The logs do not contain token_invalidated, and the failure is not fixed by treating it as a normal auth-refresh problem.

This also does not appear to be a GitHub connector authorization issue. The same account and connector can succeed from an alternate US network egress, where github_get_user_login returns the expected account login.

What steps can reproduce the bug?

Reproduction

1. Use the Turkey network route.
2. Start Codex.
3. Observe codex_apps MCP startup failure with error decoding response body.
4. Run /mcp.
5. GitHub tools may be listed.
6. Run a real tool call:

~~~text
Use the GitHub MCP tool github_get_user_login and report only the login.
~~~

1. The call fails with failed to get client and the same MCP startup error.
2. Start Codex from an alternate US network egress.
3. codex_apps initializes and github_get_user_login succeeds.
4. Returning to the Turkey route after a successful initialization may allow MCP calls to work again.

Relevant log excerpts

~~~text
WARN codex_tui::chatwidget:
failed to load full apps list; falling back to installed apps snapshot:
Failed to load apps: Failed to parse JSON response

WARN codex_core::connectors:
failed to force-refresh tools for MCP server 'codex_apps',
using cached/startup tools:
failed to get client:
MCP startup failed:
Transport send error:
HTTP request failed: error decoding response body
~~~

Real tool call failure:

~~~text
ToolCall: mcp__codex_apps__github_get_user_login {}

WARN codex_core::mcp_tool_call:
tool call error: failed to get client

Caused by:
MCP startup failed:
Transport send error:
HTTP request failed: error decoding response body
~~~

What is the expected behavior?

Expected behavior

codex_apps should initialize reliably from the Turkey network route without requiring a successful prior initialization from another network egress.

If /mcp lists GitHub tools, a real GitHub MCP call should either work or clearly report that only cached tool metadata is available.

Actual behavior

/mcp may list GitHub tools, but live MCP client creation fails. This makes the tool list misleading as a health indicator.

Additional information

Hypothesis

This looks route- or edge-sensitive.

The failure appears to happen in Codex apps discovery or the codex_apps streamable_http MCP initialization path. The CLI may be receiving an invalid, truncated, or otherwise undecodable response during MCP client initialization.

The issue may be related to chatgpt.com edge routing for apps discovery / MCP initialization, rather than local repository configuration, GitHub connector authorization, or token invalidation.

Suggested improvement

• Make codex_apps startup more resilient to transient decode failures.
• Clearly distinguish cached /mcp tool metadata from a live working MCP client.
• Add more specific logging for the failing endpoint and response class, without exposing tokens.
• Retry MCP initialization or fall back more gracefully when apps discovery fails.