Adding Stitch MCP to Codex connects a Codex session to Stitch so prompts can inspect projects, list screens, generate new designs, edit screens, and work with Stitch design systems from the same coding workflow.

Stitch's current setup docs publish the remote streamable HTTP endpoint at https://stitch.googleapis.com/mcp and support both API-key and OAuth authentication. The same Stitch docs describe API keys as the easiest path for clients that can send custom headers, while OAuth is intended for clients that need an interactive sign-in flow.

Current local verification with codex-cli 0.121.0 shows codex mcp add stitch --url https://stitch.googleapis.com/mcp saving only the remote MCP transport, and codex mcp login --help identifies OAuth as the authentication command for a named MCP server. Because the current Codex CLI does not expose a direct X-Goog-Api-Key header flag in codex mcp add --help, the clean Codex workflow is to add the Stitch endpoint first and then complete the OAuth login for stitch.

Steps to add Stitch MCP server to Codex:

  1. Add the official Stitch MCP endpoint to Codex under the server name stitch.
    $ codex mcp add stitch --url https://stitch.googleapis.com/mcp
    Added global MCP server 'stitch'.

    The current Codex CLI stores this as a remote streamable HTTP entry that is shared with the Codex IDE extension through the same saved MCP configuration.

  2. Retrieve the saved MCP entry in JSON to confirm that Codex stored the expected remote transport.
    $ codex mcp get stitch --json
    {
      "name": "stitch",
      "enabled": true,
      "disabled_reason": null,
      "transport": {
        "type": "streamable_http",
        "url": "https://stitch.googleapis.com/mcp",
        "bearer_token_env_var": null,
        "http_headers": null,
        "env_http_headers": null
      },
      "enabled_tools": null,
      "disabled_tools": null,
      "startup_timeout_sec": null,
      "tool_timeout_sec": null
    }

    The decisive fields are transport.type = streamable_http and transport.url = https://stitch.googleapis.com/mcp. The null header fields are expected immediately after codex mcp add.

  3. List configured MCP servers and confirm that the stitch entry is enabled in the current Codex configuration.
    $ codex mcp list
    ##### snipped #####
    
    Name    Url                                Bearer Token Env Var  Status   Auth
    stitch  https://stitch.googleapis.com/mcp  -                     enabled  Unsupported

    The success state for this page is the stitch row with the correct URL and an enabled status. On an unauthenticated Stitch entry, the current Codex CLI can still show Unsupported in the Auth column before the OAuth flow is completed.

  4. Authenticate the saved stitch entry through Codex's OAuth flow before using Stitch tools.
    $ codex mcp login stitch

    Stitch's current setup docs support OAuth for clients that require a sign-in flow instead of manual key headers, and current Codex CLI help identifies codex mcp login stitch as the matching authentication step for this saved server entry.

    The browser sign-in flow grants the saved stitch entry access to the selected Stitch account and workspace. Use the intended account, and revoke that access later with codex mcp logout stitch if the machine or workspace should no longer keep it.

  5. Start Codex and send a Stitch prompt that requires the new server.
    $ codex

    After the login flow completes, a prompt such as List my Stitch projects. or Create a new Stitch project named Landing page redesign. proves that Codex can reach Stitch instead of relying on local repo context alone.