Repository navigation
Unknown parameter: 'input[0].internal_chat_message_metadata_passthrough'. #30161
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.623.30605
What subscription do you have?
Azure API
What platform is your computer?
Darwin 25.4.0 arm64 arm
What issue are you seeing?
Unknown parameter: 'input[0].internal_chat_message_metadata_passthrough' after updated to latest version.
What steps can reproduce the bug?
Unknown parameter: 'input[0].internal_chat_message_metadata_passthrough' after updated to latest version.
What is the expected behavior?
No response
Additional information
No response
Activity
github-actions commentedon Jun 26, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
zm1990s commentedon Jun 30, 2026
Newer versions(Version 26.623.70822 • Released Jun 30, 2026) still have this issue, can anyone take a look?
zm1990s commentedon Jul 1, 2026
CC analysis result:
I found the bug. Here's the issue:
Root cause: In client.rs:793 and client.rs:1084, the code strips internal_chat_message_metadata_passthrough from the request when the provider !is_openai(). However, is_openai() in model-provider-info/src/lib.rs:394 only returns true when the provider name is exactly "openai" — it does not include Azure.
But internal_chat_message_metadata_passthrough is an OpenAI-internal field that Azure OpenAI doesn't support either. The condition should be checking whether the provider supports this field, not just whether it's literally "openai". Looking at the pattern in supports_remote_compaction(), it's clear that Azure is treated as an OpenAI-compatible provider for most things — but the passthrough stripping check only strips for non-OpenAI, so when your Azure endpoint is correctly detected as Azure but not as is_openai(), the field is stripped. Wait, let me re-read:
Actually the logic is the opposite: the field is kept (not stripped) only when is_openai() is true, and stripped for everyone else. Since is_openai() returns false for Azure, the field should be stripped... but you're still seeing the error. This means your Azure endpoint is not being detected as Azure by is_azure_responses_provider() — so it falls through to neither stripping nor... wait, the stripping happens for !is_openai(), which is true for Azure too.
Let me re-read more carefully:
Ran
Check OPENAI_PROVIDER_NAME constant
Now I see it. Let me check how users configure the Azure provider:
Ran 2 commands
Now I have the full picture. Here's the diagnosis:
The Bug
The error occurs because internal_chat_message_metadata_passthrough is an OpenAI-internal field that is being sent in the request to Azure OpenAI, which doesn't recognize it.
The fix is in codex-rs/core/src/client.rs:793 and line 1084. The stripping condition is:
if !self.state.provider.info().is_openai() {
// strip the passthrough field
}
is_openai() (model-provider-info/src/lib.rs:394) returns true only when the provider name == "OpenAI". It does not return true for Azure. This means when you use an Azure endpoint, is_openai() is false and... the field is stripped.
Wait — that means it should be stripped for Azure. You're getting the error, which means the field is not being stripped. This points to your Azure endpoint URL not being recognized by is_azure_responses_provider() — your URL doesn't contain any of these markers:
"openai.azure.", "cognitiveservices.azure.", "aoai.azure.",
"azure-api.", "azurefd.", "windows.net/openai"
So with an unrecognized URL, codex is treating it like a generic OpenAI-compatible provider — and looking at the logic again, the stripping at line 793 runs for !is_openai(), which would be true... let me re-check.
Actually — re-reading the logic: !is_openai() is true for Azure → passthrough is stripped. So if you're still getting the error, one of two things is happening:
Your provider is configured with name "OpenAI" but pointing to an Azure endpoint via base_url. In that case is_openai() returns true, stripping is skipped, and the field goes to Azure which rejects it.
You're using the openai provider entry with a custom base_url pointing to Azure. Same effect.
This is the actual bug: the stripping guard should be is_openai() && !is_azure_responses_endpoint(), not just is_openai(). The condition needs to also strip for Azure even when the provider name is "OpenAI". The correct fix in client.rs:793:
// Before (wrong — Azure OpenAI also doesn't support this field):
if !self.state.provider.info().is_openai() {
// After (correct):
if !self.state.provider.info().is_openai()
|| provider.is_azure_responses_endpoint() {
Workaround until fixed:
In your Codex config, set the provider name to "azure" (or any name other than "OpenAI"), not "OpenAI", so the Azure Azure endpoint gets is_openai() == false and the passthrough field gets stripped correctly.
zm1990s commentedon Jul 1, 2026
Workaround：
Adding the following lines to config.toml file.
coollx commentedon Jul 1, 2026
Thank you. This works for me!
Forest-Fairy commentedon Jul 2, 2026
hello tks at first. I found it can change the provider's name to fix it, this can avoid of losing the chatting histories.
model_provider = "OpenAI"
[model_providers.OpenAI]
name='custom'
noscripter commentedon Aug 25, 2026
FYI, I cleaned some of my custom skills located in both
~/.agents/skillsand~/.codex/skillsand my local compiled codex cli works well again. 😂