Codex Apps generate tool names >64 chars, causing Meta Muse Spark 1.3 Responses requests to fail with HTTP 400

Summary

When using meta/muse-spark-1.3-contributor through OpenRouter in Codex, requests fail with HTTP 400 whenever Codex Apps are enabled.

The provider error is:

Provider returned error

{"error":{"message":"Provider returned error","code":400,"metadata":{"raw":"{\"error\":{\"code\":null,\"message\":\"\`name\` must be at most 64 characters, got 66\",\"param\":\"name\",\"type\":\"invalid_request_error\"}}","provider_name":"Meta","is_byok":false}}}

Disabling Codex Apps with:

-c 'features.apps=false'

makes the exact same request succeed.

This appears to be caused by Codex Apps exposing namespaced tools whose flattened function names exceed Meta's 64-character tool/function name limit.

Environment

Codex: OpenAI Codex v0.155.0-alpha.2.6
OS: macOS
Provider: OpenRouter
Model: meta/muse-spark-1.3-contributor
API: Responses API

Provider configuration:

model_provider = "openrouter"
model = "meta/muse-spark-1.3-contributor"

[model_providers.openrouter]
name = "OpenRouter"
base_url = "https://openrouter.ai/api/v1"
wire_api = "responses"

[model_providers.openrouter.auth]
command = "/usr/bin/security"
args = ["find-generic-password", "-s", "codex-openrouter", "-w"]

Reproduction

1. Normal Codex execution

codex exec \
  -m meta/muse-spark-1.3-contributor \
  --skip-git-repo-check \
  "Reply with exactly: hello"

Result:

OpenAI Codex v0.155.0-alpha.2.6
--------
model: meta/muse-spark-1.3-contributor
provider: openrouter
--------

ERROR: {"error":{"message":"Provider returned error","code":400,"metadata":{"raw":"{\"error\":{\"code\":null,\"message\":\"\`name\` must be at most 64 characters, got 66\",\"param\":\"name\",\"type\":\"invalid_request_error\"}}","provider_name":"Meta","is_byok":false}}}

2. Disable Codex Apps

codex exec \
  -m meta/muse-spark-1.3-contributor \
  --skip-git-repo-check \
  -c 'features.apps=false' \
  "Reply with exactly: hello"

Result:

codex
hello

So the only meaningful change required to make the model work is:

[features]
apps = false

Additional isolation

I also tested the following:

• Direct OpenRouter /responses request to meta/muse-spark-1.3-contributor: works
• Direct OpenRouter request with reasoning enabled: works
• Clean CODEX_HOME with only the OpenRouter provider configured: works
• All manually configured MCPs disabled: still fails
• features.plugins=false: still fails
• node_repl disabled: still fails
• features.apps=false: works

This strongly isolates the issue to the Codex Apps tool surface rather than OpenRouter, Muse, reasoning, user MCPs, plugins, or node_repl.

Likely cause

Codex sends namespaced tools in the Responses payload. Some Codex Apps namespaces/tool names appear to exceed Meta's maximum supported function name length once flattened.

For example, a flattened name of this shape:

mcp__codex_apps__codex_document_control___execute_document_command

is 66 characters long.

Meta's backend rejects the entire request when any tool name exceeds 64 characters:

`name` must be at most 64 characters, got 66

The raw Codex Responses request also contains nested namespace/tool structures, so the oversized name may only be produced when those namespaces are converted into provider-compatible function names.

Expected behavior

Codex should ensure model-visible tool/function names comply with the target provider/model's constraints.

For providers with a 64-character maximum, Codex could:

• truncate and deterministically hash long tool names,
• use shorter generated aliases and map tool calls back internally,
• or otherwise normalize names before sending the request.

At minimum, enabling Codex Apps should not make a supported custom provider/model unusable because of generated tool names.

Workaround

Currently:

[features]
apps = false

allows meta/muse-spark-1.3-contributor to work normally.

This is functional, but it disables the entire Codex Apps tool surface rather than only addressing the incompatible tool names.

Start by tracing Codex Apps tool-name flattening into the Responses payload, focusing on the example that produces a 66-character name. Check how tool-call names are mapped back internally, then add coverage showing names stay within the provider limit without breaking dispatch; validate with the reproduced Meta Muse request and the apps=false comparison.