›_ Codex Issues
Codex Issues / #33011

Getting 400 error in one of my session ["invalid_request_error"]

Open 💬 3 comments Opened Jul 14, 2026 by agn-7
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

I get the following error in middle of one of my session in both CLI and VScode extension. I also tried to close the session and open it up again using codex resume but the same happened!

■ Error running remote compact task: {
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "code": "invalid_value",
    "message": "Invalid 'input[284].output[1].image_url'. Expected a valid URL, but got a value with an invalid format.",
    "param": "input[284].output[1].image_url"
  },
  "status": 400
}
> codex --version
codex-cli 0.144.4

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

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

  • #32287

Powered by Codex Action

mirray-u · 1 month ago

<img width="776" height="86" alt="Image" src="https://github.com/user-attachments/assets/0c969d11-2ed6-466f-800a-7e4a679a3e83" />

how to fix this?

sighmon · 28 days ago

Seeing a similar error after a codex resume on codex-cli 0.146.0 Intel Mac:

■ {
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "[ApiIdParam] [input[13].id] [invalid_id_prefix] Invalid 'input[13].id': 'review_rollout_user'. Expected an ID that begins with 'msg'."
  },
  "status": 400
}

For me I was able to get codex to repair it in a new session with a backup session and surgical repair. It reported:

• Yes. The session transcript contains a malformed synthetic message ID:

  "id": "review_rollout_user"

  The sequence is:

  1. An older /review inserted that special message into the transcript at /Users/human/.codex/sessions/2026/07/17/rollout-2026-07-17T11-49-03-<snip>.jsonl:652.
  2. Compaction copied it into replacement_history at /Users/human/.codex/sessions/2026/07/17/rollout-2026-07-17T11-49-03-<snip>.jsonl:713.
  3. When “Please fix that” replayed the compacted history, the API validated input[13].id, expected a msg... ID, and rejected the entire request at /Users/human/.codex/sessions/2026/07/17/rollout-2026-07-17T11-49-03-<snip>.jsonl:829.

  So this is a Codex transcript/compaction bug, not a problem with your prompt, repository, or ElevenLabs code. The large history probably caused the compaction that exposed it, but token usage is not itself the error.

  codex resume 019f6dde-... will likely remain broken because it reloads the same malformed history. The safe workaround is a new session with the review comment pasted in. The official troubleshooting guidance likewise recommends starting a focused new chat for a stuck
  session and using /feedback to submit the affected transcript (Codex troubleshooting (https://learn.chatgpt.com/docs/reference/troubleshooting.md)).

  Your installed CLI is codex-cli 0.146.0. I haven’t modified the transcript. A surgical repair may be possible by backing it up and removing the two invalid id fields, but direct transcript editing is unsupported and riskier than starting a fresh session.


› Please do a backup and try the surgical repair.


• I’ll make a timestamped sibling backup first, repair only the two review_rollout_user ID fields in a temporary copy, validate every JSONL record, and then replace the original transcript. The backup will remain available for rollback.

• The backup succeeded. I’m now applying the minimal two-field removal to a temporary copy and checking that the repaired transcript remains valid JSONL before touching the live session file.

• Validation passed: 829 records still parse, line count is unchanged, and the file is exactly 54 bytes smaller—the two 27-byte invalid ID fields. I’m replacing the live transcript now, then I’ll verify it against both the repaired copy and backup.

• The live file now matches the validated repair and contains no invalid IDs. I’m doing one minimal end-to-end resume test with a “reply only” prompt; this is necessary because merely opening the transcript would not exercise the API validation that previously failed.

• The surgical repair worked.

  - Backup: /Users/human/.codex/sessions/2026/07/17/rollout-2026-07-17T11-49-03-<snip>.jsonl.bak-20260731T1128ACST
  - Removed only the two invalid "id":"review_rollout_user" fields.
  - All 842 current JSONL records validate.
  - End-to-end resume test returned SESSION_REPAIR_OK without the previous API error.