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_v2 path.

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.

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.

  • #28592

Powered by Codex Action

Nicolas0315 · 2 months ago

I prepared a focused branch for this:

What changed:

  • Remote compaction v2 now counts both ResponseItem::Compaction and ResponseItem::ContextCompaction as valid compaction output items.
  • This matches the rest of the compaction pipeline, which already retains both variants.
  • Added a regression test for a stream that emits an extra assistant output item plus a ContextCompaction output item.

Verification:

  • Local Windows: just fmt
  • Local Windows: just test -p codex-core collect_compaction_output_accepts_context_compaction_item
  • Local Windows: just test -p codex-core collect_compaction_output
  • Local Windows: cargo check --manifest-path codex-rs\Cargo.toml -p codex-core
  • Local Windows: git diff --check
  • SSH rtx4090: just test -p codex-core collect_compaction_output
  • SSH cyberagent-mac-m5max: fresh clone + git apply + cargo test --manifest-path codex-rs/Cargo.toml -p codex-core collect_compaction_output

I 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: rustc link smoke test fails because link.exe resolves incorrectly / MSVC build tools are unavailable.
  • nicolas-macbook-pro: cargo/rustc are not in PATH; just is installed.
etraut-openai contributor · 1 month ago

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 /feedback and open a new bug report.