Product or interface
CLI - interactive TUI
Use case and problem
When opening a new MiniMax Code window or starting a new mcode process, pressing the Up key often cannot retrieve prompts that were submitted in an earlier window or session. This makes it difficult to reuse or correct a recent prompt, even though the user expects prompt history to be available across newly opened windows.
This is separate from restoring a still-waiting queue item in #321: the requested behavior is browsing previously submitted prompt history after a new window has been opened.
Desired behavior
- A newly opened window should load the user's persisted prompt history.
- Pressing
Up in an empty Composer should retrieve the most recent prior prompt, then older prompts on repeated presses, including prompts submitted from another recently opened window when available.
- History should be scoped appropriately to the user/profile and should not mix unrelated users or profiles.
- Multiline prompts and prompts containing attachments or special input should retain their editable form where supported.
- If no persisted history is available, the current empty-history behavior should remain graceful.
Acceptance criteria
- Close one mcode window, open another, and use
Up to browse prompts submitted in the earlier window.
- Verify behavior with multiple concurrent windows and after a normal restart.
- Define the persistence location, retention/size policy, and any profile or workspace scoping in the documentation or configuration reference.
- Preserve the existing cursor/history behavior when the Composer is non-empty.
Would maintainers be willing to advise on the intended persistence model or accept an implementation proposal?
Product or interface
CLI - interactive TUI
Use case and problem
When opening a new MiniMax Code window or starting a new mcode process, pressing the
Upkey often cannot retrieve prompts that were submitted in an earlier window or session. This makes it difficult to reuse or correct a recent prompt, even though the user expects prompt history to be available across newly opened windows.This is separate from restoring a still-waiting queue item in #321: the requested behavior is browsing previously submitted prompt history after a new window has been opened.
Desired behavior
Upin an empty Composer should retrieve the most recent prior prompt, then older prompts on repeated presses, including prompts submitted from another recently opened window when available.Acceptance criteria
Upto browse prompts submitted in the earlier window.Would maintainers be willing to advise on the intended persistence model or accept an implementation proposal?