Windows Codex app /compact fails with remote compaction v2 expected exactly one output item
Resolved 💬 3 comments Opened Jun 25, 2026 by hcj-hub Closed Jun 29, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
Summary
The Windows Codex app fails when running /compact with a remote compaction v2 output parsing error.
Error
Error running remote compact task: Fatal error: remote compaction v2 expected exactly one compaction output item, got 0 from 2 output items
I have also seen a similar failure in another thread:
Error running remote compact task: Fatal error: remote compaction v2 expected exactly one compaction output item, got 0 from 4 output items
Environment
- Platform: Windows
- Codex app package:
OpenAI.Codex_26.616.10790.0_x64__2p2nqsd0c76g0 - App version shown by winget/Microsoft Store listing:
26.616.10790.0 - Global Codex CLI is working normally and should not be changed.
Log evidence
Codex app logs show remote_compaction_v2 enabled:
Features enabled enabledFeatures="enable_request_compression, remote_compaction_v2, collaboration_modes, personality, request_rule, image_generation, resize_all_images, image_detail_original, workspace_dependencies, guardian_approval, apps_mcp_path_override, apply_patch_streaming_events, workspace_owner_usage_nudge, thread_tools, unified_exec, enable_mcp_apps, apps, plugins, tool_call_mcp_elicitation"
There was also a related app-side compact failure in the logs:
Failed to run pre-sampling compact
Relevant local log directory:
C:\Users\Administrator\AppData\Local\Codex\Logs\2026\06\25
Troubleshooting already tried
- Closed and reopened the Codex app.
- Repaired the Codex app from Windows app settings.
- Reinstalled the Codex app.
- The problem still occurs after reinstalling.
- The global Codex CLI works normally, so this appears specific to the Windows Codex app or the remote
remote_compaction_v2path.
Expected behavior
/compact should summarize the current visible conversation and continue the thread normally.
Actual behavior
/compact fails with the remote compaction v2 error above and does not produce a compacted thread state.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I prepared a focused branch for this:
Nicolas0315:codex/remote-compact-context-compaction0e08e56a2 fix(core): accept context compaction outputWhat changed:
ResponseItem::CompactionandResponseItem::ContextCompactionas valid compaction output items.ContextCompactionoutput item.Verification:
just fmtjust test -p codex-core collect_compaction_output_accepts_context_compaction_itemjust test -p codex-core collect_compaction_outputcargo check --manifest-path codex-rs\Cargo.toml -p codex-coregit diff --checkrtx4090:just test -p codex-core collect_compaction_outputcyberagent-mac-m5max: fresh clone +git apply+cargo test --manifest-path codex-rs/Cargo.toml -p codex-core collect_compaction_outputI attempted to open an upstream PR, but GitHub returned:
Nicolas0315 does not have the correct permissions to execute CreatePullRequest.Other SSH nodes were probed but blocked by local toolchain state:
nicolas2025: cargo/rustc shims are 0-byte files.rtx5060ti:rustclink smoke test fails becauselink.exeresolves incorrectly / MSVC build tools are unavailable.nicolas-macbook-pro: cargo/rustc are not in PATH;justis installed.Thanks for reporting this problem. Until recently, Codex used a separate endpoint and server-side logic for compaction. We recently switched to a more robust approach where the compaction logic is moved locally using the same endpoint as normal turns. This eliminates "remote compaction" errors and increases the stability and reliability of compaction operations. If you see further problems with compaction, please use
/feedbackand open a new bug report.