invalid_request_error: Invalid 'input[15].arguments': string too long

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

• #10506

Powered by Codex Action

have the same issue with latest 0.107.0 cli mode (not exec), I see "Invalid 'input[119].arguments': string too long. Expected a string with maximum length 1048576, but got a string with length
2261315 instead.

happened with spark but changing models doesnt fix the session

{ "error": { "message": "Invalid 'input[531].arguments': string too long. Expected a string with maximum length 1048576, but got a string with length 1508785 instead.", "type": "invalid_request_error", "param": "input[531].arguments", "code": "string_above_max_length" } }

{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "[StringParam] [input[85].arguments] [string_above_max_length] Invalid 'input[85].arguments': string too long. Expected a string with maximum length 1048576, but
got a string with length 1420421 instead."
  },
  "status": 400
}

Codex Spark. But swapping back to another model with the existing session doesn't resolve the problem.

> codex --version
codex-cli 0.129.0

same issue for me

Any updates on this?

Definitely the same issue. Any solution?

I am also seeing this issue, tried changing the reasoning level since changing the model doesn't seem to work either but the issue is still present.

Additional reproduction from Codex Desktop on macOS:

After the UI displayed “Context automatically compacted”, the session failed with:

[StringParam] [input[413].arguments] [string_above_max_length]
Invalid 'input[413].arguments': string too long.
Expected a string with maximum length 1048576, but got a string with length 1279780 instead.

This occurred in the same thread after automatic context compaction. The error prevents the turn from continuing.

After the UI displayed “Context automatically compacted”, the session failed with:

Already restarted my app nothing change and im up to date with the latest version:
Version 26.707.72221

Proposed fix (not submitted as a PR because external code contributions are invitation-only; see contributing guidelines).

This report is a concrete input[*].arguments reproduction of the older oversized replay payload family reported in #10506, while #13270 captures the function-call-arguments variant.

Patch outline

At the request-history formatting boundary in codex-rs/core/src/client_common.rs:

1. Identify completed FunctionCall items whose arguments string is above a conservative 1,000,000-character limit.
2. Replace only those replayed arguments with a small valid JSON placeholder.
3. Preserve the call_id and matching FunctionCallOutput.
4. Leave unfinished calls and the original in-memory history unchanged.
5. Add a regression test covering the automatic-compaction failure.

The proposed patch is implemented and locally validated on branch agent/oversized-tool-arguments-pr, commit 9a00d3c00c.

Validation:

• cargo test -p codex-core client_common::tests: 7 passed
• git diff --check: passed
• Clippy reaches the changed code but is blocked by the pre-existing clippy::large_enum_variant error in core-plugins/src/manifest.rs.

This avoids blindly truncating active tool calls and prevents a completed historical call from making the next Responses API request invalid.

Additional persistence and recovery evidence from Codex CLI 0.147.0 on Linux
x86_64, using gpt-5.6-sol:

The generated exec custom tool call had a payload.input length of exactly
3,726,964 characters. Of those, 3,726,835 were spaces. The non-space portion
looked like the beginning and end of a malformed JavaScript string containing
an apply_patch request.

This did not fail only for the originating turn. Codex retained the oversized
tool call in the local session JSONL. Every subsequent user message resent it
as input[114].input and failed with the same HTTP 400 before the model could
answer. Automatic remote compaction also failed with the same error, leaving no
recovery path through the CLI.

I recovered the session manually by preserving the exact response item and
replacing only its oversized payload.input with a short placeholder. The
matching failed tool result and all 310 history records were retained. After
that repair, codex exec resume succeeded and the model answered a controlled
test prompt.

This suggests two useful safeguards:

1. Reject or truncate a generated tool argument before persisting it if it

exceeds the API field limit.

1. Make resume and compaction able to omit or truncate an already-invalid

history item instead of resending it indefinitely.

I can provide the exact offending response item privately if useful. I would
not post the complete session because it contains personal conversation data.

I'm experiencing a very similar error in the Windows Codex app while using 5.3 Codex Spark:

[StringParam] [input[308].arguments] [string_above_max_length] Invalid 'input[308].arguments': string too long. Expected a string with maximum length 1048576, but got a string with length 1686845 instead.

This has caused the chat to be irrecoverable forcing me to start a new chat in the project. Any follow up prompt leads to the same error being thrown every time.

@JeeveStobs I had the same problem and let another codex session repair it. I just asked "him" how we did it:

› how did we basically repair that? i want to write just a few line to another guy who has the same problem

• We found the session's JSONL file under ~/.codex/sessions/ and backed it up. One tool-call record contained a multi-
  megabyte payload.input, mostly spaces, which made every retry and compaction fail. We replaced only that string with a
  short placeholder, kept the record and call ID intact, then resumed the session with codex exec resume <session-id>.

Hope they still fix it upstream (does not seem so difficult), but for the meantime this helps...

@ezander thanks, that worked and I was able to archive the two "broken" chats.