Allow queueing /new or /compact commands

Resolved 💬 6 comments Opened Jan 12, 2026 by darinkishore Closed Apr 22, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What feature would you like to see?

Currently, you can only run /new or /compact when an agent completes their task entirely .

instead, for more powerful orchestration capabilities, if we can queue /new or /compact that would be lovely.

example, i have the following prompt :

Please implement phase 2 fully ! Please first use bd prime; then run bd ready.

  Then, please look thru the realtime epic, and run the core beads/jj workflow to work through every bead in phase 2--you can do this just by finishing a bead, and running bd ready next.
Show, claim, and properly Finish every phase 2 bead in full. Ensure that you fulfill all acceptance criteria per bead. 

 Be thorough and precise. You may fix other technical debt or confusions if you find them.

For a concise overview of the full realtime system with proper types, please first reference beads_stateright_models/src/realtime_types_sketch.rs .
And very importantly, if anything is ambigious, please refernece the original plan (REALTIME_PLAN.md for more information). 

  please create new commits for each bead (jj workflow) . make sure cargo check and clippy are happy before moving on to the next task . 

  If you are creating new types, first read docs/philosophy/type_design.md .
  If you are handling errors, please read docs/philosophy/error_design.md .
  If you are creating traits, please read docs/philosophy/trait_design.md .
  If you are writing tests, please read docs/philosophy/test_design.md.

  Encode everything into typestate that you can . Preserve codebase quality . This is a complex distributed system, so implement carefully.

Run cargo check, cargo clippy (treat warnings seriously), and cargo test proactively and often. Before completing each bead, run the relevant cargo check/clippy/tests for the touched crates/modules. Run the full test suite at the end of each phase.

After each of these, I would want to run /new so that I can queue up the next prompt, and leave codex running without me having to go outside of codex and script it .

Additional information

_No response_

View original on GitHub ↗

6 Comments

etraut-openai contributor · 7 months ago

Thanks for the feature request.

A few thoughts that may help you out.

For /new, most users typically instantiate a new copy of the TUI or use codex exec to run another non-interactive agent.

Running a manual compaction using /compact should no longer be needed with the latest models because they perform auto-compaction when the context window becomes nearly full. Manual compaction should largely be a thing of the past.

darinkishore · 7 months ago

@etraut-openai

thanks for responding !

re: /new -- I don't want to do headless--would like visibility as it works, even if I'm not looking at it all the time.

marcohefti · 7 months ago

Second this for /model - often times I start up codex and want to go to the model selection but I always need to wait a few seconds for the MCP's to be ready, so would be great if I could queue it instead

codengine · 7 months ago
Running a manual compaction using /compact should no longer be needed with the latest models because they perform auto-compaction when the context window becomes nearly full. Manual compaction should largely be a thing of the past.

It is still necessary for two reasons:

  • it will often not continue with its current task but would repeat older ones (#8648)
  • in a multi step plan, it doesn't run compact at the end but in between, even if there is > 30% left

I always manual compact if I assume that my next task would reach the 30% barrier.

darinkishore · 7 months ago
It is still necessary for two reasons: ... I always manual compact if I assume that my next task would reach the 30% barrier.

i try to, but because most of my execution is for long periods of time after i've confirmed it's working well, i often cannot. and i don't want to lose the visibility into the process and go purely codex exec . if we could queue /new or /compact, we get the best of both worlds, visibility + orchestration power for a single codex thread .

etraut-openai contributor · 4 months ago

This feature is included in the latest CLI release.