Codex Desktop 26.707.31428: Slack and Atlassian codex_apps MCP handshake times out after update

Summary

After updating Codex Desktop, every built-in codex_apps connector call for Slack and Atlassian fails during MCP startup with a 30-second handshake timeout.

The same Slack connector had worked earlier in the workflow, including creating a Slack draft. After the desktop update, both Slack and Atlassian started failing consistently. The in-app Browser plugin still works and can open an authenticated Jira page, so the failure appears scoped to the built-in codex_apps MCP path.

Related: #24785, which reports the same handshake failure on an older desktop version with Gmail and GitHub connectors.

Environment

• macOS: 26.5.2 (build 25F84)
• Codex Desktop bundle version: 26.707.31428
• Desktop build: 5059
• Codex Framework: 150.0.7871.101
• codex-cli: 0.144.0-alpha.4
• Auth mode: ChatGPT
• Affected connectors:
• Slack
• Atlassian Rovo (Jira/Confluence)

Reproduction

1. Update Codex Desktop to 26.707.31428.
2. Start a desktop thread with previously working and authorized Slack and Atlassian connectors.
3. Invoke a read-only Slack tool such as mcp__codex_apps__slack_slack_search_channels.
4. Invoke a read-only Atlassian tool such as mcp__codex_apps__atlassian_rovo_getjiraissue.

Actual behavior

Both calls fail with:

tool call error: failed to get client

Caused by:
    MCP startup failed: timed out handshaking with MCP server after 29.999999792s

This reproduces across multiple retries and affects both connectors at the same time.

Expected behavior

Codex Desktop should initialize the built-in codex_apps MCP server and invoke the already-authorized Slack and Atlassian connector tools.

Additional observations

• The failure began immediately after the desktop update.
• Slack and Atlassian fail with the identical MCP startup error.
• The in-app Browser plugin remains functional and can access an authenticated Jira page.
• Local shell tools remain functional.
• Direct calls to https://chatgpt.com/backend-api/wham/apps were not attempted in this environment, so this report does not claim direct backend reachability.