Codex Desktop scheduled automation cannot initialize codex_apps connectors; manual rerun succeeds

What version of Codex is running?

0.128.0 from C:/Users/ivan4.000/.codex/version.json:

{"latest_version":"0.128.0","last_checked_at":"2026-05-04T00:53:10.761878800Z","dismissed_version":null}

Environment

• Product: Codex Desktop app
• Platform: Windows
• Automation execution environment: local
• Model configured for the automation: gpt-5.5, reasoning effort medium
• Connected apps involved: Gmail and GitHub through codex_apps

What issue are you seeing?

A scheduled Codex Desktop automation that needs Gmail fails because the codex_apps MCP client cannot initialize. The same failure affects both Gmail and GitHub app connector calls, so it does not appear to be a Gmail query or Gmail authorization issue.

Later, a manual rerun in Codex Desktop succeeds and Gmail can be read normally. That makes the automation unreliable: if scheduled automations require the user to manually rerun or restart Codex Desktop, they lose their purpose.

Automation config

The automation is a daily local cron-like task:

version = 1
id = "gmail-ai"
kind = "cron"
name = "Gmail AI 文章推荐"
status = "ACTIVE"
rrule = "DTSTART:20260508T090000\nRRULE:FREQ=DAILY"
model = "gpt-5.5"
reasoning_effort = "medium"
execution_environment = "local"
cwds = ["~"]

The task is read-only from Gmail: search recent messages and summarize AI/newsletter content. It does not archive, label, delete, or mark messages.

Failure details

During the failed run, all real app connector calls failed immediately with the same MCP startup error.

Gmail _get_profile failed:

tool call error: failed to get client

Caused by:
    MCP startup failed: handshaking with MCP server failed: Send message error Transport [rmcp::transport::worker::WorkerTransport<rmcp::transport::streamable_http_client::StreamableHttpClientWorker<codex_rmcp_client::http_client_adapter::StreamableHttpClientAdapter>>] error: Transport channel closed, when send initialized notification

Gmail _search_emails failed with the same error:

tool call error: failed to get client

Caused by:
    MCP startup failed: handshaking with MCP server failed: Send message error Transport [rmcp::transport::worker::WorkerTransport<rmcp::transport::streamable_http_client::StreamableHttpClientWorker<codex_rmcp_client::http_client_adapter::StreamableHttpClientAdapter>>] error: Transport channel closed, when send initialized notification

GitHub _get_profile was used as a control probe and failed with the same failed to get client / Transport channel closed, when send initialized notification error.

Timeline observed locally

• 2026-05-08: Gmail automation failed with failed to get client / Transport channel closed, when send initialized notification.
• 2026-05-08 later: after restarting/reopening Codex Desktop, Gmail _get_profile succeeded and the Gmail automation could proceed.
• 2026-05-10 09:33 Asia/Shanghai: the scheduled/background Gmail automation attempt again failed. Gmail _get_profile, Gmail _search_emails, and GitHub _get_profile all failed with the same codex_apps MCP startup error.
• 2026-05-10 11:15 Asia/Shanghai: a manual rerun in Codex Desktop succeeded. Gmail _get_profile returned the expected account, Gmail search returned recent emails, and the automation completed without modifying mail state.

Expected behavior

Scheduled Desktop automations should initialize installed app connectors reliably, or retry/recover if the codex_apps MCP bridge is temporarily unavailable.

If connector initialization fails, the scheduled task should surface a clear actionable error and distinguish:

• app connector authorization problems
• network/edge failures
• codex_apps MCP bridge/runtime startup failures
• cached tool metadata vs a live working connector client

Actual behavior

The scheduled automation failed before any Gmail data could be read because live app connector calls could not get a codex_apps client.

Manual rerun later succeeded, which suggests this is not caused by the Gmail query, the automation prompt, or missing Gmail authorization.

Why this seems distinct from existing issues

I found related issues, but they seem to cover adjacent MCP/Streamable HTTP failures rather than scheduled Desktop automations:

• #16550: codex_apps MCP startup fails on wham/apps with proxy/reachability context.
• #19576: codex_apps MCP fails to initialize on a specific network route.
• #21534 / #21535: intermittent startup failure for the official OpenAI Developer Docs MCP server.
• #20982 and #21903: Streamable HTTP handshake failures during initialized notification for external MCP servers.

This report is specifically about Codex Desktop scheduled automations using installed app connectors, where Gmail/GitHub both fail during codex_apps startup but later manual execution succeeds.

Additional notes

• This is not a request to change Gmail behavior; the task is read-only and works when the connector initializes.
• A local write-permission issue for the automation memory file was separately fixed by trusting C:/Users/ivan4.000/.codex/automations; that did not address the connector startup failure.
• It would help if scheduled automations either preflight app connector health, retry codex_apps initialization, or mark the task as failed with a connector-runtime-specific diagnostic instead of requiring the user to manually restart/rerun Codex Desktop.