codex mcp add --url writes a config that codex's own parser then rejects

<!-- quality-ok -->

Bug

Adding a remote/streamable-HTTP MCP server via the documented CLI command produces a ~/.codex/config.toml entry that codex's own config loader then rejects, breaking every codex invocation (including codex whoami, codex cloud list, codex mcp list) until the entry is manually removed.

Repro

codex mcp add figma --url "https://mcp.figma.com/mcp" --bearer-token-env-var FIGMA_API_KEY
codex whoami

Resulting ~/.codex/config.toml entry:

[mcp_servers.figma]
url = "https://mcp.figma.com/mcp"
bearer_token_env_var = "FIGMA_API_KEY"

Running any codex subcommand afterward fails with:

Error loading config.toml: url is not supported for stdio
in `mcp_servers.figma`

Reproduced twice: codex mcp remove figma then re-adding with the exact documented --url/--bearer-token-env-var flags produces the same broken entry each time — this isn't a stale/hand-edited config issue, it's add's own output.

Expected

Either codex mcp add --url writes a config the CLI can load (e.g. an explicit transport = "streamable_http" key), or the loader accepts a bare url key as sufficient to infer streamable-HTTP transport.

Environment

codex-cli 0.143.0 (Homebrew/Cask, macOS)

Impact

One codex mcp add --url ... call blocks the entire CLI (cloud + local) globally until the user manually deletes the offending [mcp_servers.*] block — no scoped failure or graceful degradation for a single broken MCP server.