Codex App: context compaction fails with invalid_enum_value for `context_compaction`
What version of the Codex App are you using (From “About Codex” dialog)?
Codex CLI/runtime: codex-cli 0.137.0 Global npm package: @openai/codex@0.137.0 Codex App version: unknown / not shown in this report
What subscription do you have?
ChatGPT Plus
What platform is your computer?
Microsoft Windows 11, Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
After Codex automatically compacts context, the thread shows an internal schema/enum error:
[ItemParam] [input[6]] [invalid_enum_value] Invalid value: 'context_compaction'. Supported values are:
'additional_tools', 'apply_patch_call', 'apply_patch_call_output', 'code_interpreter_call',
'compaction', 'compaction_trigger', 'computer_call', 'computer_call_output',
'custom_tool_call', 'custom_tool_call_output', 'file_search_call', 'function_call',
'function_call_output', 'image_generation_call', 'item_reference', 'local_shell_call',
'local_shell_call_output', 'mcp_approval_request', 'mcp_approval_response', 'mcp_call',
'mcp_list_tools', 'message', 'reasoning', 'shell_call', 'shell_call_output',
'tool_search_call', 'tool_search_output', and 'web_search_call'.
This happens immediately around the "Context compacted" event. It looks like the Codex App/runtime is sending or replaying a context_compaction item type, but the receiving schema only accepts compaction / compaction_trigger and other listed item types.
A full uninstall/reinstall did not fix related Codex schema errors on this machine, so this appears to be a client/server schema mismatch or persisted thread replay compatibility issue rather than a normal local install problem.
Screenshot attached.
What steps can reproduce the bug?
- Use Codex App on Windows 11.
- Continue a thread until automatic context compaction happens.
- After the "Context compacted" marker appears, send another message or continue the thread.
- Observe the invalid_enum_value error for
context_compaction.
What is the expected behavior?
Context compaction should complete cleanly and the thread should remain usable. If context_compaction is a valid newer item type, the app/server should accept it or normalize it to a supported item type during replay/compaction.
Additional information
This may be related to recent Codex context compaction schema mismatch reports, but the exact enum value here is different.
Related examples:
24 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I reviewed the suggested duplicates #25191 and #25030.
This may be related, but it does not look like the exact same failure.
Those reports are about remote compaction failing with:
unknown variant auto, expected high or originalMy report is about a different schema/enum error after compaction:
[invalid_enum_value] Invalid value: 'context_compaction'The accepted item types listed in the error include
compactionandcompaction_trigger, but notcontext_compaction.So this may share the same root cause class (client/server schema mismatch during compaction), but the failing enum value and validation path appear different.
Are you using an Azure as a model provider, or are you using the OpenAI provider?
If you're able to repro this, please use
/feedbackand post your session ID here.I am using the OpenAI provider, not Azure.
This reproduces in my current Codex Desktop thread as well. When I trigger context compaction, it immediately fails with:
[invalid_enum_value] Invalid value: 'context_compaction'Environment:
Session / rollout ID from the local session filename:
019e9561-a875-7932-835a-a4598c2e34eaI will also try to run
/feedbackfrom the affected thread and post the feedback ID if it returns one.Quick update: I tried to run
/feedbackin the affected Codex Desktop thread, but the Desktop app shows "No commands" for/feedback, so I cannot generate a feedback ID from this UI.Adding another reproducible data point.
Environment
What I observed
I hit the same error during automatic context compaction:
The interesting part is that:
So in my case this does not appear to be caused by an outdated client or a corrupted old thread.
Feedback ID:
019e96af-5c00-7162-ba9c-d842072f577cI had this and was able to get it fixed on MacOS, for Windows you may need to go spelunking in the filesystem to do the same.
codex-app has a version of the codex cli bundled inside it. I noticed that in my build of codex-app (149.0.7827.54), the bundled cli is version 0.137.0-alpha.4. In my case, I could rename the file and symlink an up to date CLI (0.137.0) in its place. On MacOS, the
codexfile to replace is inCodex.app/Contents/Resources; I don't know the filesystem layout of the Windows installation, but you'll be looking for acodex.exethat outputscodex-cli 0.137.0-alpha.4when executed with--version.Replace that with an up to date codex-cli and you _might_ be golden.
compaction stop working after updating to latest codex version with same error. FIX please
<img width="804" height="449" alt="Image" src="https://github.com/user-attachments/assets/d600f7d2-1a9a-406d-9aa2-c861174d768f" />
running into this issue on my version Version 26.602.71036
Running into this issue on the latest version.
https://github.com/openai/codex/issues/27005
got the same error on the latest version (26.602.71036 ) of codex app on macos running over ssh on a linux server which has the latest version of codex cli
Same here. Running via SSH from macOS desktop app to linux. Same exact error.
Running into this on
26.601.21317codex desktop over ssh on a linux machine whose codex cli version is0.130.0Mitigated by continuing the turn in cursor's codex extension
Had the same issue earlier, I pointed 5.4 mini to this page and said I have the same problem. He fixed it in 5 minutes.
I ran into the same context_compaction / invalid_enum_value issue when using Codex Desktop on Windows to connect to a remote macOS host over SSH.
In my case, the problem seems to be related to the Codex CLI version on the remote host.
The Codex Desktop SSH connection page showed:
Version: 0.130.0
On the remote macOS host, I confirmed:
which -a codex
/opt/homebrew/bin/codex
codex --version
codex-cli 0.130.0
npm list -g @openai/codex --depth=0
@openai/codex@0.130.0
After updating the remote macOS Codex CLI:
npm uninstall -g @openai/codex
npm install -g @openai/codex@latest
hash -r
codex --version
the issue stopped happening for that SSH connection.
So at least in my case, the error was not caused by Windows Codex Desktop alone. It was triggered only when the remote SSH host was still using an older Codex CLI version (0.130.0). My Windows → Ubuntu SSH connection did not reproduce the issue, while Windows → macOS did until I updated the remote CLI.
Solved.
BUT... even after updating the codex cli on the ssh server to 0.139.0 ~/.local/bin/codex was pointing at the old 0.130.0
So, make sure it points to the updated version
Yes, exactly. One more thing I noticed: after updating the Codex CLI on the SSH host, I also had to disable and re-enable the existing SSH connection in Codex Desktop. Otherwise the old connection still seemed to keep using/caching the previous Codex path/version.
After re-enabling the SSH connection and confirming that the connection page showed the updated Codex version, the issue stopped happening for me.
We are seeing the same
context_compaction/invalid_enum_valuefailure as well.I filed #27423 with details from a Linux environment running
codex-cli 0.130.0, but after reviewing the existing reports it looks like the same underlying issue. I am closing #27423 as a duplicate and will follow this thread instead.This fixed it for me too.
I had already upgraded the Codex CLI on the SSH host, but the error kept happening until I restarted / re-enabled the SSH connection in Codex Desktop. After reconnecting and confirming the connection page showed the updated Codex version, the
context_compactionissue stopped happening.<img width="3420" height="1978" alt="Image" src="https://github.com/user-attachments/assets/c826639b-3e88-485a-b744-e57bd696b0c7" />
I found a similar button that I hadn’t seen before. Looks like it may have been added in the latest version. I’ll click it now and give you feedback in a minute on whether it solved the issue. Stay tuned, friends!)
<img width="1571" height="419" alt="Image" src="https://github.com/user-attachments/assets/f4b13de0-da22-43c1-8877-e09183291be1" />
Yes, it works! The problem disappeared immediately!
Closing as a duplicate of #23018.