Regression in codex-cli 0.143.0: Existing conversation fails with Unknown parameter: input[...].namespace, but works in 0.142.0

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #31665
• #31746
• #31748
• #31744
• #31697

Powered by Codex Action

+1

+1

I can reproduce the same input[...].namespace failure on the current macOS desktop app, so this is not limited to CLI 0.143.0 or WSL.

Environment

• Codex Desktop: 26.721.31836
• Embedded Codex: 0.146.0-alpha.3.1
• macOS arm64
• ChatGPT auth / OpenAI provider
• Reproduced on 2026-07-24

Additional evidence

The affected existing thread originally used gpt-5.5. After a response-annotation/review turn, its recorded model changed to the internal codex-auto-review model and remained there for subsequent normal turns.

The rollout then contained six response items shaped like:

{
  "type": "custom_tool_call",
  "name": "exec",
  "namespace": "exec",
  "call_id": "<redacted>",
  "input": "<redacted>"
}

Every later attempt to continue that thread failed with HTTP 400:

[ObjectParam] [input[65].namespace] [unknown_parameter]
Unknown parameter: 'input[65].namespace'.

Restarting the updated desktop app did not repair the thread. New threads continued to work. thread_dynamic_tools had no namespaced rows for this thread, so this does not appear to be stale MCP registration.

Controlled recovery / A-B result

For diagnosis only (after backing up local state), I quit the app and removed only the six "namespace":"exec" properties from the affected custom_tool_call history items. JSONL validity and SQLite integrity remained OK.

After reopening the same thread, the previously failing prompt completed successfully. However, that successful turn on embedded Codex 0.146.0-alpha.3.1 immediately persisted two new custom_tool_call items with "namespace":"exec". This shows that editing old history only unblocks one replay; the current client/model path can recreate the incompatible field.

As a local mitigation I stripped the two new fields and changed that thread's stored model from codex-auto-review back to the user's normal model. I am not proposing manual history/database editing as an end-user workaround; this was only an A/B diagnostic with backups.

Suspected compatibility gap

This looks like an output/replay schema mismatch:

• the current client/model path emits and persists namespace on custom_tool_call;
• a later full-history replay endpoint rejects that same property as an unknown input parameter.

This may be related to #30302, which intentionally preserves custom-tool namespaces through app-server replay. The replay endpoint and client serialization need to agree on whether CustomToolCall.namespace is accepted. Separately, it may be worth checking why a response-annotation turn left the user thread persisted on codex-auto-review instead of returning to the selected model.

I can provide additional sanitized field-level diagnostics if useful, but I will not upload full rollout files because they contain private conversation and local-environment data.

Follow-up verification

After applying the model-state mitigation, I verified two consecutive turns in the original thread. Both turns completed successfully on gpt-5.6-sol, both invoked the local shell tool, and the persisted items were normal unnamespaced calls:

{"type":"function_call","name":"exec_command","namespace":null}

No HTTP 400 recurred. This strengthens the correlation with the thread being left on codex-auto-review: the same repaired history is stable after returning to the normal model, while the auto-review path had emitted custom_tool_call(name="exec", namespace="exec") and poisoned later full-history replay.

Additional Windows reproduction (2026-07-28)

I can reproduce the same input[...].namespace failure in the current Windows desktop app.

Environment

• Codex Desktop: 26.721.4979.0
• Embedded Codex: 0.146.0-alpha.3.1
• Windows x64
• ChatGPT authentication / OpenAI provider

Important difference from the earlier reports: this now affects brand-new threads, not only conversations created before an upgrade.

Reproduction

1. Start a new local thread.
2. Let the agent invoke the custom exec tool.
3. The persisted rollout contains an item shaped like {"type":"custom_tool_call","name":"exec","namespace":"exec"} (call IDs and inputs omitted).
4. On the next continuation, the thread fails with HTTP 400, for example:

[ObjectParam] [input[9].namespace] [unknown_parameter] Unknown parameter: 'input[9].namespace'.

1. Creating another new thread and repeating the exec call reproduces the failure again. A longer affected thread reported input[13].namespace.

Direct first-class tool calls (for example normal shell/function calls) continue to work because they do not persist the namespaced custom_tool_call. Avoiding functions.exec is therefore a mitigation, but it is not a complete product fix when a capability is only exposed through that tool.

This began reproducing on 2026-07-28 even though the desktop package was installed on 2026-07-25, which suggests a client/backend/model rollout interaction rather than project state. Restarting and creating a new thread do not prevent recurrence once exec is invoked.

I am not attaching complete rollout files because they contain private conversation and local-environment data.

Current macOS reproduction with exact two-stage failure (2026-07-30)

I can reproduce this again on the current macOS desktop-hosted Codex surface. I inspected the local rollout records without editing them.

Environment

• Codex Desktop: 26.721.81911 (build 5973)
• Embedded Codex: 0.146.0-alpha.3.1
• macOS 26.5.2 arm64
• ChatGPT authentication / OpenAI provider
• Observed on 2026-07-30

Exact poisoned item and failure sequence

Immediately after a successful compaction, the rollout persisted this response item (IDs and input redacted):

{
  "type": "custom_tool_call",
  "status": "completed",
  "name": "exec",
  "namespace": "exec",
  "call_id": "<redacted>",
  "input": "<redacted>"
}

The next recorded output was:

unsupported custom tool call: execexec

This shows the same field first breaks local dispatch: namespace=exec plus name=exec is routed as a namespaced tool and misses the plain built-in exec handler.

The malformed item remains in persisted conversation history. On the next full replay/resume, the request fails before model execution:

[ObjectParam] [input[129].namespace] [unknown_parameter]
Unknown parameter: 'input[129].namespace'.

The index is reconstructable from the persisted order:

• compacted replacement history: 125 items;
• two Responses Lite prefix items;
• subsequent reasoning and assistant message at input[127] and input[128];
• the namespaced custom_tool_call is therefore input[129].

Forking the conversation does not help because the fork copies the poisoned item and fails at the same fixed index.

Scope

This is not tied to one repository or one conversation. In the local Codex state I found:

• 40 unique failed turn IDs;
• 15 independent rollout files;
• multiple top-level threads plus subagents;
• failing indices 8, 9, 12, 13, 32, 33, 129, 228, 260;
• replay failures observed with both codex-auto-review and gpt-5.6-sol thread state.

Fresh threads can still work when custom_tool_call(name="exec") is persisted with namespace: null, but any thread containing the non-null self-namespace is poisoned for later replay.

Version boundary

The protocol source matches the regression shape:

• rust-v0.142.0: CustomToolCall has no namespace field.
• rust-v0.143.0: optional serialized namespace was added.

The current client persists that field, while the replay validator used by this conversation rejects it. This looks like a compatibility gap between custom-tool output persistence, built-in tool routing, and full-history replay.

Current service incident

OpenAI Status currently reports elevated errors affecting ChatGPT conversations, with mitigation applied and recovery being monitored. However, the earliest local input[...].namespace failure was at 2026-07-30T12:01:34Z, about 2.5 hours before the incident's published 14:35Z start, so the incident correlates with today's elevated failures but does not fully explain this regression's timeline.

Suggested recovery requirements

A complete fix likely needs all three:

1. validate/sanitize self-namespaces on plain built-in custom tools before dispatch;
2. omit or accept CustomToolCall.namespace consistently on full-history replay;
3. recover already-poisoned persisted threads automatically (forking currently preserves the bad item).

I am not attaching full rollout files because they contain private conversation and local-environment data, but I can provide additional sanitized field-level evidence if useful.

I can reproduce this regression on macOS with both Codex Desktop and newer CLI versions.

Environment:

• Codex Desktop build: 26.727.40816
• Bundled Codex CLI: 0.146.0-alpha.9.2
• Standalone Codex CLI: 0.144.4
• macOS
• CC Switch: 3.19.0

Observed:

• New conversations work normally.
• Existing conversations containing prior namespaced/custom tool history fail on every new turn with:

[ObjectParam] [input[n].namespace] [unknown_parameter] Unknown parameter: 'input[n].namespace'.

• The failure affects normal models as well as codex-auto-review.
• Local logs contain 12 occurrences across July 30–31.
• CC Switch's Codex proxy is currently not active (enabled=0, live_takeover_active=0), so this is reproducible without requests being routed through its local proxy.

This appears to be a Codex history replay/serialization compatibility regression, consistent with this issue.

Could the Codex client strip unsupported namespace fields when replaying older input items, or could the backend accept them? Please confirm the target release for a fix or provide a supported migration/workaround for affected conversations.

Auto-review / guardian reproduction on Windows (2026-08-01)

I can reproduce the same custom_tool_call / namespace round-trip failure described in this Windows reproduction, but in my case it occurs inside the hidden automatic-approval reviewer thread.

Environment

• Codex Desktop: 26.727.6591.0
• Embedded Codex: 0.146.0-alpha.9.2
• Windows x64
• Permission mode: automatic approval review (approvals_reviewer = "auto_review")

User-visible error

Automatic approval review failed: {
  "error": {
    "message": "Unknown parameter: 'input[49].namespace'.",
    "type": "invalid_request_error",
    "param": "input[49].namespace",
    "code": "unknown_parameter"
  }
}

What the local rollout shows

1. The parent task requests an action that requires approval.
2. Codex starts a guardian subagent using the hidden codex-auto-review model.
3. The reviewer performs a read-only check through the custom exec tool.
4. Its rollout persists a completed response item shaped like:

``json
{"type":"custom_tool_call","name":"exec","namespace":"exec","status":"completed"}
``

1. A matching custom_tool_call_output is recorded.
2. The reviewer continuation then fails with HTTP 400 because the retained item is replayed as input and input[49].namespace is rejected.
3. The parent task surfaces that transport/schema failure as Automatic approval review failed, so the requested action is blocked before the guardian can return an approval assessment.

The namespaced custom_tool_call is the only retained response item with a namespace field in the affected guardian rollout. I found the same error propagated through two separate parent-task / guardian-session pairs on the same day, so this was not a single stale-thread occurrence.

This suggests the bug affects not only normal conversation continuation but also the dedicated auto-review path. Starting a fresh parent task is not a reliable workaround if the new guardian reviewer invokes exec again. Switching from automatic review to manual user approval avoids invoking the affected reviewer path, but the product-level fix still appears to require stripping the output-only/self-referential namespace before replay, accepting it on input, or preventing it from being emitted for the built-in custom exec tool.

I am omitting full rollout files, call IDs, tool inputs, paths, and conversation content because they contain private local data.

Somewhat ironically, my first attempt to submit this very comment through Codex was itself blocked by the same automatic-review failure—this time as Unknown parameter: 'input[13].namespace'.

Isolated to the guardian request builder: main-model path sanitizes namespace, auto-review path does not (2026-08-01)

Reproducing the auto-review variant reported above on macOS CLI. I have full outbound HTTP bodies for this session, which lets me narrow the failure past "the field round-trips" to the specific serialization path that emits it.

Environment

• Codex CLI 0.146.0 (standalone, not desktop)
• macOS 26.5.2 arm64
• ChatGPT authentication / OpenAI provider
• approvals_reviewer = "guardian_subagent", main model gpt-5.6-luna, effort xhigh
• Code mode active (exec custom tool)
• Observed 2026-07-30 and 2026-07-31

User-visible error

This action was rejected due to unacceptable risk.
Reason: Automatic approval review failed: {
  "error": {
    "message": "Unknown parameter: 'input[118].namespace'.",
    "type": "invalid_request_error",
    "param": "input[118].namespace",
    "code": "unknown_parameter"
  }
}

The offending item, from the actual logged request body

Rather than infer the index from the rollout, I pulled the guardian's outbound POST body out of the local trace log (~/.codex/logs_2.sqlite, target codex_http_client::transport). The request is model: "codex-auto-review" with 127 input items, and input[118] is exactly:

{
  "type": "custom_tool_call",
  "id": "<redacted>",
  "status": "completed",
  "call_id": "<redacted>",
  "name": "exec",
  "namespace": "exec",
  "input": "<redacted JS>"
}

Neighbouring items for context — only the custom_tool_call carries the extra key:

114 reasoning               ['encrypted_content', 'id', 'summary', 'type']
115 message                 ['content', 'id', 'phase', 'role', 'type']
116 message                 ['content', 'id', 'role', 'type']
117 reasoning               ['encrypted_content', 'id', 'summary', 'type']
118 custom_tool_call  exec  ['call_id', 'id', 'input', 'name', 'namespace', 'status', 'type']
119 custom_tool_call_output ['call_id', 'id', 'output', 'type']
120 message                 ['content', 'id', 'role', 'type']

The narrowing result: it is the reviewer's serializer, not the model or the history

I parsed every logged request body in this session's history and counted custom_tool_call items against the presence of namespace:

| model | bodies with custom_tool_call | custom_tool_call items | items carrying namespace |
|---|---:|---:|---:|
| codex-auto-review (guardian) | 24 | 24 | 24 |
| gpt-5.6-luna (main) | 74 | 7141 | 0 |
| gpt-5.6-sol | 54 | 1460 | 0 |
| gpt-5.6-terra | 10 | 1185 | 0 |

9,786 custom_tool_call items go out on main-model requests over the same conversation history and not one carries namespace. Every one of the 24 that goes out on the auto-review path does.

Cross-checked at the level of a single item: for one specific call_id, 8 logged requests contain that item, all 8 are codex-auto-review, all 8 carry namespace. The identical item on the main path is emitted without it.

So the main request builder already strips this field somewhere before the wire. The reviewer builder serializes ResponseItem without that sanitization step. That looks like the whole bug — the fix is presumably applying the same normalization on the reviewer path rather than changing the type.

For reference, on current main the field is serialized whenever set, on both variants:

// codex-rs/protocol/src/models.rs — CustomToolCall (and FunctionCall)
#[serde(default, skip_serializing_if = "Option::is_none")]
namespace: Option<String>,

skip_serializing_if = Option::is_none only omits it when absent; once code mode sets it to Some("exec") it is emitted, so nothing in the type prevents this. This is consistent with the bisect earlier in the thread — #30302 "Preserve namespaces on custom tool calls" (merged 2026-06-27, shipped 0.143.0) is where preservation was introduced.

Two notes that may matter for triage

1. Rollout persistence is inconsistent, so the rollout is a misleading source of truth. My 2026-07-30 rollout persisted "namespace":"exec" on its exec items. My 2026-07-31 rollout persisted zero namespace fields across 125 exec calls — yet the guardian request from that same session still emitted namespace and still 400'd. Anyone triaging by grepping rollout JSONL will get false negatives; the field is present in the request regardless of whether it was persisted.

2. Fail-closed converts a client-side 400 into a risk verdict, and this is arguably the more damaging half. The error text tells the model it was rejected for unacceptable risk, and appends anti-circumvention language instructing it not to retry or route around the decision. In my case the agent correctly obeyed: it concluded its environment was denying network and MCP access on policy grounds, stopped attempting the task, and reported to me that access was restricted. Nothing had actually been denied — a malformed outbound request was being reported as a security decision.

Worth distinguishing transport/serialization failures from genuine policy denials in that code path, whatever happens with the namespace fix. A 400 from the reviewer endpoint is an infrastructure failure and should surface as one; as written it silently degrades agent behavior for the rest of the session in a way that is very hard to attribute.

Scope

This gates MCP tool calls as well as shell escalations — the specific call that tripped it for me was an MCP tool invocation, not a command. And it is not intermittent: once any exec call is in history, every subsequent approval review in that session fails, permanently.

Happy to provide the full redacted request body if that would help.

Still happens on Codex Mac Desktop, even on the new conversations.

"unknown_parameter: input[20].namespace"

This is from conversation created Today (03.08.2026), on version "26.727.51351" of Codex Mac Desktop

Unsubscribe

On Mon, Aug 3, 2026 at 9:09 AM locycloid @.***> wrote:

locycloid left a comment (openai/codex#31754) <https://github.com/openai/codex/issues/31754#issuecomment-5166706176> Still happens on Codex Mac Desktop, even on the new conversations. "unknown_parameter: input[20].namespace" This is from conversation created Today (03.08.2026), on version "26.727.51351" of Codex Mac Desktop — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/31754?email_source=notifications&email_token=AKE6WS53K42L24K5H3K3SR35ICFJ7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMJWGY3TANRRG43KM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-5166706176>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKE6WS73YE5UWPARLYIQKXL5ICFJ7AVCNFSNUABFKJSXA33TNF2G64TZHM4TMNJUGE2TMNBZHNEXG43VMU5TIOBUGQ2TQNRYGA4KC5QC> . You are receiving this because you are subscribed to this thread.Message ID: @.***>

I'm experiencing the same error.

[ObjectParam] [input[7].namespace] [unknown_parameter] Unknown parameter: 'input[7].namespace'.

I'm experiencing the same error.

Hitting this exact issue too @tibo-openai this is more important than resets since this is basically blocking the auto approver from allowing normal commands

I put up a candidate fix on my fork:

Branch: https://github.com/LHMQ878/codex/tree/fix/31754-strip-namespace-guardian
Compare: https://github.com/openai/codex/compare/main...LHMQ878:codex:fix/31754-strip-namespace-guardian

Change: strip
amespace from FunctionCall / CustomToolCall in Prompt::get_formatted_input_for_request before the Responses API request is built. Local history still keeps the field for dispatch.

Why: #30302 preserved namespaces for local routing, but the Responses API rejects input[].namespace (unknown_parameter). That hits resumed threads and especially guardian/auto-review (which serializes those history items).

Test: cargo test -p codex-core --lib client_common::tests (all passed locally).

I was not able to open a PR against openai/codex from this account (API returns 404 / CreatePullRequest permission). Happy for a maintainer to cherry-pick or open the PR from the branch above.