Add first-class Codex setup to the MCP client picker

[M-DGayle]

Problem

Settings → MCP currently provides first-class setup recipes for Claude Code, Cursor, VS Code, Claude Desktop, Windsurf, and Zed, plus a generic fallback. OpenAI Codex supports Streamable HTTP MCP servers and OAuth, but Codex users must currently infer the setup from the generic option.

Proposed change

Add a Codex option to the existing MCP client picker with the native local-client flow:

codex mcp add openship --url https://<your-openship>/api/mcp
codex mcp login openship

The recipe should note that local Codex surfaces share MCP configuration (desktop app, CLI, and IDE extension) and may need to restart after the server is added.

Update the MCP documentation to include the same native Codex flow and clearly distinguish local Codex clients from hosted/cloud execution. A private self-hosted OpenShip endpoint should not be presented as reachable by a hosted Codex task unless that environment actually has network access to it.

Why this should fit the existing architecture

OpenShip already provides the required protocol and authorization surfaces:

• Streamable HTTP JSON-RPC at /api/mcp
• OAuth protected-resource and authorization-server discovery
• dynamic client registration
• authorization-code flow with S256 PKCE
• read-only/full-control and resource-scoped grants
• per-call permission enforcement

A compatibility probe against a current self-hosted OpenShip instance confirmed the expected unauthenticated 401 challenge and advertised OAuth metadata. The current Codex CLI exposes the matching mcp add --url and mcp login commands.

This proposal should therefore require no new endpoint, schema, dependency, or authentication behavior.

Suggested implementation scope

• Add a Codex brand entry and setup recipe in apps/dashboard/src/app/(dashboard)/settings/_components/McpConnection.tsx.
• Update apps/web/content/docs/mcp.mdx and the dashboard settings documentation where the supported client list is described.
• Keep OAuth as the recommended path; retain the existing static-token fallback for users who intentionally choose it.
• Avoid unrelated MCP server or authorization changes.

Validation approach

• Complete the real Codex OAuth flow against self-hosted OpenShip.
• Confirm Codex can initialize, list tools, and make an allowed read-only call.
• Confirm the OpenShip grant remains scoped and revocation disconnects the client.
• Run the existing test suite, dashboard typecheck/lint, and formatting checks.
• Add automated coverage only where it exercises observable recipe-selection/rendering behavior; avoid a constant-presence test that would not catch a real regression.

If this scope and command flow look right, Madd Technologies would be happy to implement the focused dashboard/docs change and link the resulting PR to this issue.

[Hydralerne]

we will add it, thank you