Queueable manual compaction at turn boundaries

Resolved 💬 2 comments Opened Mar 19, 2026 by 137alpha Closed Mar 19, 2026

What variant of Codex are you using?

CLI/TUI, with related core and app-server behavior

What feature would you like to see?

Allow manual compaction to be queued while a turn is already running, so it executes at the next safe turn boundary instead of being rejected or immediately replacing the active turn.

Concretely, I want to be able to intentionally express this workflow:

  1. let the current turn finish
  2. compact history
  3. then continue with the next queued prompt(s)

This is useful when I already know I want a compaction barrier in the middle of a planned prompt sequence.

Additional information

Current behavior appears split across layers:

  • In the TUI, /compact is disabled while a task is in progress.
  • In the existing queued-input UX, plain user messages can be queued while busy, but compaction cannot.
  • In core/app-server paths, starting compaction appears to replace the active task rather than waiting for a safe boundary.

That means there is currently no first-class way to say "queue a compaction after the current turn."

Why this would help:

  • It preserves intentional multi-step workflows.
  • It avoids interrupting active work just to force a context reset.
  • It removes the need to remember to run compaction later.

Example desired behavior:

  • current turn is still running
  • user queues /compact
  • user queues the next prompt
  • system finishes the active turn, runs compaction, then resumes queued work in documented order

A few design questions seem worth deciding explicitly:

  • Should queued compaction be FIFO with queued user messages, or a special boundary action?
  • If multiple compaction requests are queued, should they collapse into one pending compaction?
  • Should app-server thread/compact/start gain similar queued semantics, or should there be separate immediate vs queued APIs?
  • Should queued compaction be visible and cancelable before it starts?

I verified the current behavior from the implementation before filing this. The relevant paths were the TUI slash-command gating, queued user-message handling, and the core/app-server compaction task startup path.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗