Fastmail MCP intermittently fails in recurring automations and hides auth/startup errors

Fastmail MCP intermittently fails in recurring automations and hides auth/startup errors

Summary

When a recurring automation depends on Fastmail MCP for inbox and calendar access, the automation can fail before the actual Fastmail calls start. In the failing case, Fastmail tools never become callable in the automation context, even though Fastmail can work in other Codex contexts on the same account.

Impact

• Recurring automations cannot reliably read a Fastmail inbox mailbox.
• Recurring automations cannot reliably read Fastmail calendar events.
• The user-facing result degrades to "tools unavailable" instead of surfacing a concrete Fastmail auth or startup error.

Observed Behavior

In failing runs, logs repeatedly show:

waiting for MCP server tools while building tool list server_name=fastmail has_cached_tool_info_snapshot=false startup_complete=true

and do not later show:

listed MCP server tools while building tool list server_name=fastmail tool_count=18

In successful runs, that later listed MCP server tools line does appear and Fastmail becomes callable.

Additional Signal

A manual external codex exec run surfaced a concrete Fastmail MCP auth/startup error:

AuthRequired(AuthRequiredError { www_authenticate_header: "Bearer resource_metadata=\"https://api.fastmail.com/.well-known/oauth-protected-resource/mcp\", scope=\"https://www.fastmail.com/dev/mcp\"" })

and on shutdown:

failed to initialize MCP client during shutdown: MCP startup failed: handshaking with MCP server failed: ... Auth required

After refreshing Fastmail OAuth with:

codex mcp login fastmail

the external run succeeded and Fastmail inbox/calendar access worked again.

Why This Looks Like A Product Bug

• The recurring automation path often reports only that Fastmail tools did not surface.
• A more direct manual run can expose a real auth/startup error.
• That suggests the automation path is masking or mishandling Fastmail MCP startup/auth state instead of surfacing it clearly.

Reproduction

1. Configure Fastmail MCP in Codex.
2. Create a recurring automation that depends on Fastmail inbox and calendar access.
3. Run the automation multiple times over a period where Fastmail auth may need refresh or where MCP startup is unstable.
4. Observe that some runs fail before search_email / search_events are ever called.
5. Compare with a manual external codex exec run using the same Fastmail account.

Expected

• If Fastmail auth is invalid or expired, the automation should surface that exact auth problem.
• If auth is valid, the automation should enumerate Fastmail tools consistently and proceed to search_email / search_events.

Actual

• The automation can stall during Fastmail MCP tool enumeration.
• The user-facing result is generic tool unavailability instead of an actionable Fastmail error.
• A manual external run can recover after codex mcp login fastmail, which suggests the automation path is not handling the same failure mode well.

Workaround

• Refresh Fastmail auth with codex mcp login fastmail.
• Use an external scheduled codex exec runner instead of the built-in recurring automation runner.

Requested Fix

1. Make recurring automation runs surface concrete Fastmail MCP auth/startup errors.
2. Make Fastmail tool enumeration in recurring automations as reliable as in normal manual Codex runs.
3. Avoid degrading a real Fastmail auth failure into a generic "tools unavailable" result.