Fantastical MCP initialization fails when Codex advertises codex/auth-change

Summary

In fresh Codex Desktop tasks, Fantastical’s native MCP helper starts but fails during initialize when Codex includes:

"experimental": {
  "codex/auth-change": {}
}

The helper returns JSON-RPC error -32603:

Internal error: The data couldn’t be read because it isn’t in the correct format.

No Fantastical tools are registered afterward.

A controlled local A/B test against fresh helper processes shows that omitting only the experimental field makes initialization and tools/list succeed.

Version / Environment

• macOS 26.6.2
• Apple Silicon
• Codex Desktop bundled CLI: 0.154.0-alpha.6.2
• Fantastical: 4.1.19
• Native helper:

/Applications/Fantastical.app/Contents/Helpers/FantasticalMCP.app/Contents/MacOS/FantasticalMCP

Reproduction

1. Configure Codex Desktop to use Fantastical’s native MCP helper.
2. Start a fresh Codex Desktop task.
3. Observe that the helper process starts.
4. Codex sends an MCP initialize request containing the nonempty capabilities.experimental object shown above.
5. The helper returns JSON-RPC -32603, and Codex registers no Fantastical tools.

Expected

Codex should be able to omit or negotiate this optional experimental capability for servers that do not accept it, allowing Fantastical’s MCP helper to initialize normally.

Actual

Initialization fails with:

JSON-RPC -32603
Internal error: The data couldn’t be read because it isn’t in the correct format.

The helper process exits with status 0, but no Fantastical tools become available in the task.

Controlled A/B evidence

Each test used a fresh Fantastical helper process. All initialization fields were identical except for this capability delta.

A — capability present

"capabilities": {
  "experimental": {
    "codex/auth-change": {}
  }
}

Result:

• initialize fails with exact JSON-RPC error -32603
• Error message: Internal error: The data couldn’t be read because it isn’t in the correct format.
• No tools/list
• Process exits 0

B — experimental omitted

Result:

• initialize succeeds
• Negotiated protocol version: 2025-03-26
• tools/list succeeds
• Process exits 0

Standalone direct-helper and isolated app-server tests had also succeeded without the problematic block.

This A/B test establishes the effect of codex/auth-change versus omission for Fantastical. It does not establish whether Fantastical rejects every nonempty experimental object. Other helpers have shown failures with arbitrary unknown experimental keys, but that broader case was not tested against Fantastical here.

Safety / data minimization

• tools/call count: 0
• No calendar query was made
• No calendar data or identifiers were read
• No write tool was called
• No persistent files were created
• ~/.codex/config.toml remained unchanged
• The helper’s raw tools/list includes read and write tools, but the Codex configuration allows only queryCalendars and queryCalendarItems; create, modify, and delete tools are disabled
• Private configuration details and user-specific paths are intentionally omitted

No shim or wrapper is requested. The desired fix is for Codex to omit or negotiate the capability per MCP server.

Related issues

Potentially related:

• https://github.com/openai/codex/issues/44458
• https://github.com/openai/codex/issues/45269
• https://github.com/openai/codex/issues/45326

This is the first Fantastical-specific reproduction found during this investigation; this is not a claim that no earlier report exists.

The issue does not name implementation files or tests. Start by locating Codex’s MCP initialize request and capability-negotiation handling, then reproduce against a fresh Fantastical helper with and without the experimental field. Done means initialization succeeds and tools/list is available when the server does not accept the optional capability.