Codex Desktop auto-compaction fails with an invalid enum error when a long-running thread is automatically compacted.

Resolved 💬 3 comments Opened Jun 11, 2026 by junn-sk Closed Jun 12, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

Codex 26.608.12217

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 24.6.0 arm64 arm

What issue are you seeing?

Codex Desktop auto-compaction fails with an invalid enum error when a long-running thread is automatically compacted.

Feedback ID:
019eb60c-29f9-77d3-a533-464dfd6bac40

Error message:

[ItemParam] [input[1]] [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 occurs immediately after Codex Desktop shows that the context was automatically compacted.

Environment / workflow:

  • Codex Desktop App version: Codex 26.608.12217
  • Codex Desktop says it is on the latest version.
  • I am using Codex Desktop with a remote Mac workflow.
  • The remote Codex CLI is up to date.
  • This happens during long-running coding sessions with file edits and tool calls.

Workarounds already tried:

  1. I added the following to ~/.codex/config.toml:

[features]
remote_compaction_v2 = false

  1. I restarted Codex Desktop.
  2. I confirmed after restart that remote_compaction_v2 was still disabled using:

codex features list

  1. I also tested OMO PostCompact hooks separately. They did not produce malformed output.
  2. The issue still reproduced after Codex Desktop restart and after confirming remote_compaction_v2=false.

Impact:
Long-running Codex Desktop threads become unusable once automatic compaction triggers. The coding operation may partially complete and file edits may be applied, but the thread then fails with the invalid enum error and cannot continue reliably.

Expected behavior:
Codex Desktop should not send an unsupported item type named “context_compaction” to the API. If compaction metadata is needed, it should use a supported item type such as “compaction” or “compaction_trigger”, or filter internal-only item types before submitting the request.

Actual behavior:
When automatic context compaction triggers, Codex sends or replays an item with type “context_compaction”. The API rejects it because “context_compaction” is not one of the supported input item types.

Steps to reproduce:

  1. Open Codex Desktop.
  2. Use a remote Mac workflow.
  3. Start or continue a long-running coding thread.
  4. Perform enough file edits/tool calls for automatic context compaction to trigger.
  5. Codex Desktop shows that the context was automatically compacted.
  6. The next request fails with the invalid_enum_value error for “context_compaction”.

This does not appear to be caused by my project code. It appears to be a Codex Desktop auto-compaction or saved-thread replay serialization issue where an internal item type leaks into the API input.

What steps can reproduce the bug?

This issue is not caused by a specific project code snippet. I do not have a minimal standalone code snippet that reproduces it, because the failure occurs in Codex Desktop’s automatic context compaction / saved-thread replay path.

Feedback ID:
019eb60c-29f9-77d3-a533-464dfd6bac40

Codex App version:
Codex 26.608.12217

Workflow:

  • Codex Desktop App
  • Remote Mac workflow
  • Long-running coding thread with multiple file edits and tool calls
  • Remote Codex CLI is up to date
  • remote_compaction_v2=false was confirmed after restarting Codex Desktop

Reproduction steps:

  1. Open Codex Desktop App.
  2. Connect to or use a remote Mac workflow.
  3. Start a long-running coding thread in a real project.
  4. Ask Codex to perform coding work involving file reads, file edits, searches, and tests.
  5. Continue the same thread until Codex Desktop automatically compacts the context.
  6. Codex shows that the context was automatically compacted.
  7. Immediately after compaction, the next request fails with this error:

[ItemParam] [input[1]] [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’.

Observed example:
After the error, Codex still reported file edits:

  • src/reports/build_report.py
  • tests/test_report.py

This suggests the coding operation may partially apply file changes, but the thread becomes unreliable or unusable once automatic compaction/replay fails.

Workarounds already tried:

  1. Added this to ~/.codex/config.toml:

[features]
remote_compaction_v2 = false

  1. Restarted Codex Desktop.
  2. Confirmed after restart that remote_compaction_v2 remained disabled using:

codex features list

  1. Tested OMO PostCompact hooks separately; no malformed output was observed.
  2. The error still reproduced after Codex Desktop restart and after confirming remote_compaction_v2=false.

Session ID / token usage / context window usage:
I do not have a visible session ID or exact token/context-window usage from the UI. The issue consistently appears when the thread becomes long enough for Codex Desktop to trigger automatic context compaction.

What is the expected behavior?

Codex Desktop should continue the thread normally after automatic context compaction.

It should not send or replay an unsupported input item type named “context_compaction” to the API.

If compaction metadata needs to be represented in the conversation input, Codex Desktop should use a supported item type such as “compaction” or “compaction_trigger”, or filter any internal-only item types before submitting the next request.

Expected result:

  • Automatic context compaction completes successfully.
  • The long-running coding thread remains usable.
  • File edits and tool-call history are preserved correctly.
  • The next user request after compaction does not fail with invalid_enum_value.
  • Disabling remote_compaction_v2 should either prevent this compaction path or Codex should clearly use a compatible fallback path.

Actual result:
After automatic compaction, Codex Desktop fails with invalid_enum_value because “context_compaction” is included as an input item type even though it is not supported by the API schema.

Additional information

_No response_

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 months ago

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

  • #27555
  • #27511
  • #27269
  • #27267
  • #27005

Powered by Codex Action

junn-sk · 2 months ago

I am still hitting the context_compaction / invalid_enum_value issue after multiple troubleshooting steps.

Environment:

  • Platform: macOS
  • Surface: Codex Desktop
  • Connection type: remote connection to my Mac host
  • Codex app bundled CLI:

/Applications/Codex.app/Contents/Resources/codex --version
codex-cli 0.138.0-alpha.7

  • User config path:

/Users/junn_pro/.codex/config.toml

Original failure:

After a long-running Codex Desktop session reaches automatic context compaction, the thread immediately becomes unusable with:

[ItemParam] [input[786]] [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'.

The failure happens immediately after the “Context automatically compacted” event. The thread cannot continue afterward.

Troubleshooting performed:

  1. Reinstalled Codex Desktop.
  2. Updated the Codex CLI from the terminal.
  3. Verified that running codex in the terminal triggered an update flow and completed.
  4. Checked the system Codex binary:

which -a codex
/opt/homebrew/bin/codex

  1. Checked the Codex Desktop bundled CLI:

/Applications/Codex.app/Contents/Resources/codex --version
codex-cli 0.138.0-alpha.7

  1. Disconnected and reconnected the remote connection in Codex Desktop.
  2. Renamed the project folder so Codex Desktop would treat it as a new project instead of resuming the previous broken project/session.
  3. Started a new project/session after the folder rename.
  4. The same context_compaction error still occurred after automatic compaction.
  5. Tried opening/resuming the same conversation directly on the server Mac. A different schema/replay error appeared:

Missing namespace for function_call 'spawn_agent'. It does not exist in the default namespace. Round-trip the model's function_call item with its namespace field included.

  1. After reconnecting, Codex Desktop also failed to load the configuration with:

failed to load configuration: /Users/junn_pro/.codex/config.toml:10:16: unknown variant default, expected fast or flex

  1. I inspected the config:

nl -ba /Users/junn_pro/.codex/config.toml | sed -n '7,13p'

Output:

7 network_access = "enabled"
8
9 notify = ["/Users/junn_pro/.codex/computer-use/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient", "turn-ended"]
10 service_tier = "default"
11
12 [features]
13 goals = true

  1. I changed:

service_tier = "default"

to:

service_tier = "flex"

This fixed the configuration loading issue and the chat window opened again.

Current status:

  • The service_tier = "default" config issue is fixed by changing it to flex.
  • However, the main context_compaction issue still reproduces even after:
  • reinstalling Codex Desktop,
  • updating the terminal CLI,
  • reconnecting the remote connection,
  • renaming the project folder to force a new project/session,
  • and starting from a fresh project/session.

Important observation:

The Codex Desktop bundled CLI is still:

/Applications/Codex.app/Contents/Resources/codex --version
codex-cli 0.138.0-alpha.7

This seems suspicious because other comments suggest that Codex Desktop may be using its bundled CLI rather than the globally updated CLI. If the bundled alpha CLI is still responsible for serializing compaction items as context_compaction, then updating the global CLI would not fix the Desktop compaction failure.

At this point, this does not look like just an old corrupted thread. It reproduced in a new project/session after renaming the project folder. It looks more like a Codex Desktop bundled CLI / app-server schema mismatch around automatic context compaction.

ax-openai · 2 months ago

Closing as a duplicate of #27269.