mirror of
https://github.com/pchuan98/codex.git
synced 2026-07-01 00:31:56 +08:00
Felipe Coury
0bdeab330b
# TL;DR - Adds recognized slash commands to the TUI's local in-session recall history. - This is the MVP of the whole feature: it keeps slash-command recall local only: nothing is written to persistent history, app-server history, or core history storage. - Treats slash commands like submitted text once they parse as a known built-in command, regardless of whether command dispatch later succeeds. # Problem Slash commands are handled outside the normal message submission path, so they could clear the composer without becoming part of the local Up-arrow recall list. That made command-heavy workflows awkward: after running `/diff`, `/rename Better title`, `/plan investigate this`, or even a valid command that reports a usage error, users had to retype the command instead of recalling and editing it like a normal prompt. The goal of this PR is to make slash commands feel like submitted input inside the current TUI session while keeping the change deliberately local. This is not persistent history yet; it only affects the composer's in-memory recall behavior. # Mental model The composer owns draft state and local recall. When slash input parses as a recognized built-in command, the composer stages the submitted command text before returning `InputResult::Command` or `InputResult::CommandWithArgs`. `ChatWidget` then dispatches the command and records the staged entry once dispatch returns to the input-result path. Command-name recognition is the only validation before local recall. A valid slash command is recallable whether it succeeds, fails with a usage error, no-ops, is unavailable while a task is running, or is skipped by command-specific logic. An unrecognized slash command is different: it is restored as a draft, surfaces the existing unrecognized-command message, and is not added to recall. Bare commands recalled from typed text use the trimmed submitted draft. Commands selected from the popup record the canonical command text, such as `/diff`, rather than the partial filter text the user typed. Inline commands with arguments keep the original command invocation available locally even when their arguments are later prepared through the normal submission pipeline. # Non-goals Persisting slash commands across sessions is intentionally out of scope. This change does not modify app-server history, core history storage, protocol events, or message submission semantics. This does not change command availability, command side effects, popup filtering, command parsing, or the semantics of unsupported commands. It only changes whether recognized slash-command invocations are available through local Up-arrow recall after the user submits them. # Tradeoffs The main tradeoff is that recall is based on command recognition, not command outcome. This intentionally favors a simpler user model: if the TUI accepted the input as a slash command, the user can recall and edit that input just like plain text. That means valid-but-unsuccessful invocations such as usage errors are recallable, which is useful when the next action is usually to edit and retry. The previous accept/reject design required command dispatch to report a boolean outcome, which made the dispatcher API noisier and forced every branch to decide history behavior. This version keeps the dispatch APIs as side-effect-only methods and localizes history recording to the slash-command input path. Inline command handling still avoids double-recording by preparing inline arguments without using the normal message-submission history path. The staged slash-command entry remains the single local recall record for the command invocation. # Architecture `ChatComposer` stages a pending `HistoryEntry` when recognized slash-command input is promoted into an input result. The pending entry mirrors the existing local history payload shape so recall can restore text elements, local images, remote images, mention bindings, and pending paste state when those are present. `BottomPane` exposes a narrow method for recording that staged command entry because it owns the composer. `ChatWidget` records the staged entry after dispatching a recognized command from the input-result match. Valid commands rejected before they reach `ChatWidget`, such as commands unavailable while a task is running, are staged and recorded in the composer path that detects the rejection. Slash-command dispatch itself now lives in `chatwidget/slash_dispatch.rs` so the behavior is reviewable without adding more weight to `chatwidget.rs`. The extraction is behavior-preserving: the dispatch match arms stay intact, while the input flow in `chatwidget.rs` remains the single place that connects submitted slash-command input to dispatch. # Observability There is no new logging because this is a local UI recall behavior and the result is directly visible through Up-arrow recall. The practical debug path is to trace Enter through `ChatComposer::try_dispatch_bare_slash_command`, `ChatComposer::try_dispatch_slash_command_with_args`, or popup Enter/Tab handling, then confirm the recognized command is staged before dispatch and recorded exactly once afterward. If a valid command unexpectedly does not appear in recall, check whether the input path staged slash history before clearing the composer and whether it used the `ChatWidget` slash-dispatch wrapper. If an unrecognized command unexpectedly appears in recall, check the parser branch that should restore the draft instead of staging history. # Tests Composer-level tests cover staging and recording for a bare typed slash command, a popup-selected command, and an inline command with arguments. Chat-widget tests cover valid commands being recallable after normal dispatch, inline dispatch, usage errors, task-running unavailability, no-op stub dispatch, and command-specific skip behavior such as `/init` when an instructions file already exists. They also cover the negative case: unrecognized slash commands are not added to local recall.
0bdeab330b
·
2026-04-11 12:40:08 -03:00
5,275 Commits
npm i -g @openai/codex
or brew install --cask codex
Codex CLI is a coding agent from OpenAI that runs locally on your computer.
If you want Codex in your code editor (VS Code, Cursor, Windsurf), install in your IDE.
If you want the desktop app experience, run
codex app or visit the Codex App page.
If you are looking for the cloud-based agent from OpenAI, Codex Web, go to chatgpt.com/codex.
Quickstart
Installing and running Codex CLI
Install globally with your preferred package manager:
# Install using npm
npm install -g @openai/codex
# Install using Homebrew
brew install --cask codex
Then simply run codex to get started.
You can also go to the latest GitHub Release and download the appropriate binary for your platform.
Each GitHub Release contains many executables, but in practice, you likely want one of these:
- macOS
- Apple Silicon/arm64:
codex-aarch64-apple-darwin.tar.gz - x86_64 (older Mac hardware):
codex-x86_64-apple-darwin.tar.gz
- Apple Silicon/arm64:
- Linux
- x86_64:
codex-x86_64-unknown-linux-musl.tar.gz - arm64:
codex-aarch64-unknown-linux-musl.tar.gz
- x86_64:
Each archive contains a single entry with the platform baked into the name (e.g., codex-x86_64-unknown-linux-musl), so you likely want to rename it to codex after extracting it.
Using Codex with your ChatGPT plan
Run codex and select Sign in with ChatGPT. We recommend signing into your ChatGPT account to use Codex as part of your Plus, Pro, Business, Edu, or Enterprise plan. Learn more about what's included in your ChatGPT plan.
You can also use Codex with an API key, but this requires additional setup.
Docs
This repository is licensed under the Apache-2.0 License.