generated MCP tool names are too long

[bolinfest]

What version of Codex is running?

0.1.2505111730

Which model were you using?

codex-mini-latest

What platform is your computer?

unsure

What steps can reproduce the bug?

This is based on this thread from the discussion forums:

#1174 (comment)

Basically, the injected __OAI_CODEX_MCP__ delimiter can cause things to tip over the 64-character limit

What is the expected behavior?

Need to find a way to have multiple MCPs with a reliable disambiguation scheme that is less likely to trip the limit.

What do you see instead?

ERROR: unexpected status 400 Bad Request: {  "error": {    "message": "Invalid 'tools[5].name': string too long. Expected a string with maximum length 64, but got a string with length 72 instead.",    "type": "invalid_request_error",    "param": "tools[5].name",    "code": "string_above_max_length"  }}

Additional information

No response

[MinesJA]

Gave this a shot with a PR using Claude. Let me know if this helps at all or if I'm off the mark.

[CodePalAI]

This is still an issue for us

[juliuskrah]

Hey I just got the same error when attempting to use a tool from github mcp server add_pull_request_review_comment_to_pending_review

{
  "error": {
    "message": "Invalid 'tools[39].name': string too long. Expected a string with maximum length 64, but got a string with length 72 instead.",
    "type": "invalid_request_error",
    "param": "tools[39].name",
    "code": "string_above_max_length"
  }
}

[gokmev]

This appears to have regressed for Bedrock-backed model providers after #39594 raised the MCP tool-name limit from 64 to 128 bytes. Amazon Bedrock Runtime still accepts a maximum of 64 characters, so longer codex_apps MCP names pass Codex normalization but are rejected downstream.

I opened #46188 with reproduction details, version boundaries, the current proxy workaround, and a suggestion for a provider-specific or configurable limit.