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_
6 Comments
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 usecodex execto run another non-interactive agent.Running a manual compaction using
/compactshould 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.@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.
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
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 .
This feature is included in the latest CLI release.