codex

7,000 Commits 2 Branches 0 Tags

2 Commits

Include renames

Author	SHA1	Message	Date
Felipe CouryandGitHub	241136b0e9	feat(tui): show context used in plan implementation prompt (#18573 ) # Summary When a user finishes planning, the TUI asks whether to implement in the current conversation or start fresh with the approved plan. The clear-context choice is easier to evaluate when the prompt shows how much context has already been used, because the user can see when carrying the full prior conversation is likely to be less useful than preserving only the plan. <img width="1612" height="1312" alt="image" src="https://github.com/user-attachments/assets/694bcf87-8be5-4e88-a412-e562af62d5f7" /> This PR adds that context signal directly to the clear-context option while keeping the copy compact enough for the Plan-mode selection popup. # What Changed - Compute an optional context-usage label when opening the plan implementation prompt. - Show the label only on `Yes, clear context and implement`, where it informs the cleanup decision. - Prefer a percentage-used label when context-window information is available, with a compact token-used fallback when only token totals are known. - Preserve the original option description when usage is unknown or effectively zero. - Add rustdoc comments around the prompt-copy boundary so future changes keep the context label formatting and selection rendering responsibilities clear. # Testing - `cargo test -p codex-tui plan_implementation` # Notes The footer continues to show context remaining as ambient status. The implementation prompt intentionally shows context used because the user is choosing whether to clean up the current thread before implementation.	2026-04-19 14:01:58 -03:00
Felipe CouryandGitHub	d3692b14c9	feat(tui): add clear-context plan implementation (#17499 ) ## TL;DR - Adds a second Plan Mode handoff: implement the approved plan after clearing context. - Keeps the existing same-thread `Yes, implement this plan` action unchanged. - Reuses the `/clear` thread-start path and submits the approved plan as the fresh thread's first prompt. - Covers the new popup option, event plumbing, initial-message behavior, and disabled states in TUI tests. ## Problem Plan Mode already asks whether to implement an approved plan, but the only affirmative path continues in the same thread. That is useful when the planning conversation itself is still valuable, but it does not support the workflow where exploratory planning context is discarded and implementation starts from the final approved plan as the only model-visible handoff. <img width="1253" height="869" alt="image" src="https://github.com/user-attachments/assets/90023d75-c330-4919-bed8-518671c3474b" /> ## Mental model There are now two implementation choices after a proposed plan. The existing choice, `Yes, implement this plan`, is unchanged: it switches to Default mode and submits `Implement the plan.` in the current thread. The new choice, `Yes, clear context and implement`, treats the proposed plan as a handoff artifact. It clears the UI/session context through the same thread-start source used by `/clear`, then submits an initial prompt containing the approved plan after the fresh thread is configured. The important distinction is that the new path is not compaction. The model receives a deliberate implementation prompt built from the approved plan markdown, not a summary of the previous planning transcript. Both implementation choices require the Default collaboration preset to be available, so the popup does not offer a coding handoff when the fresh thread would fall back to another mode. ## Non-goals This change does not alter `/clear`, `/compact`, or the existing same-context Plan Mode implementation option. It does not add protocol surface area or app-server schema changes. It also does not carry the previous transcript path or a generated planning summary into the new model context. ## Tradeoffs The fresh-context option relies on the approved plan being sufficiently complete. That matches the Plan Mode contract, but it means vague plans will produce weaker implementation starts than a compacted transcript would. The upside is that rejected ideas, exploratory dead ends, and planning corrections do not leak into the implementation turn. The current implementation stores the latest proposed plan in `ChatWidget` rather than deriving it from history cells at selection time. This keeps the popup action simple and deterministic, but it makes the cache lifecycle important: it must be reset when a new task starts so an old plan cannot be submitted later. ## Architecture The TUI stores the most recent completed proposed-plan markdown when a plan item completes. The Plan Mode approval popup uses that cache to enable the fresh-context option and to build a first-turn prompt that instructs the model to implement the approved plan in a fresh context. Selecting the new option emits a TUI-internal `ClearUiAndSubmitUserMessage` event. `App` handles that event by reusing the existing clear flow: clear terminal state, reset app UI state, start a new app-server thread with `ThreadStartSource::Clear`, and attach a replacement `ChatWidget` with an initial user message. The existing initial-message suppression in `enqueue_primary_thread_session` ensures the prompt is submitted only after the new session is configured and any startup replay is rendered. ## Observability The previous thread remains resumable through the existing clear-session summary hint. There is no new telemetry or protocol event for this path, so debugging should start at the TUI event boundary: confirm the popup emitted `ClearUiAndSubmitUserMessage`, confirm the app-server thread start used `ThreadStartSource::Clear`, then confirm the fresh widget submitted the initial user message after `SessionConfigured`. ## Tests The Plan Mode popup snapshots cover the new option and preserve the original option as the first/default action. Unit coverage verifies the original same-context option still emits `SubmitUserMessageWithMode`, the new option emits `ClearUiAndSubmitUserMessage` with the approved plan embedded verbatim, and the clear-context option is disabled when Default mode is unavailable or no approved plan exists. The broader `codex-tui` test package passes with the updated fresh-thread initial-message plumbing.	2026-04-17 14:30:09 -03:00

Author

SHA1

Message

Date

Felipe CouryandGitHub

241136b0e9

feat(tui): show context used in plan implementation prompt (#18573 )

# Summary

When a user finishes planning, the TUI asks whether to implement in the
current conversation or start fresh with the approved plan. The
clear-context choice is easier to evaluate when the prompt shows how
much context has already been used, because the user can see when
carrying the full prior conversation is likely to be less useful than
preserving only the plan.

<img width="1612" height="1312" alt="image"
src="https://github.com/user-attachments/assets/694bcf87-8be5-4e88-a412-e562af62d5f7"
/>
    
This PR adds that context signal directly to the clear-context option
while keeping the copy compact enough for the Plan-mode selection popup.

# What Changed

- Compute an optional context-usage label when opening the plan
implementation prompt.
- Show the label only on `Yes, clear context and implement`, where it
informs the cleanup decision.
- Prefer a percentage-used label when context-window information is
available, with a compact token-used fallback when only token totals are
known.
- Preserve the original option description when usage is unknown or
effectively zero.
- Add rustdoc comments around the prompt-copy boundary so future changes
keep the context label formatting and selection rendering
responsibilities clear.

# Testing

- `cargo test -p codex-tui plan_implementation`

# Notes

The footer continues to show context remaining as ambient status. The
implementation prompt intentionally shows context used because the user
is choosing whether to clean up the current thread before
implementation.

2026-04-19 14:01:58 -03:00

Felipe CouryandGitHub

d3692b14c9

feat(tui): add clear-context plan implementation (#17499 )

## TL;DR

- Adds a second Plan Mode handoff: implement the approved plan after
clearing context.
- Keeps the existing same-thread `Yes, implement this plan` action
unchanged.
- Reuses the `/clear` thread-start path and submits the approved plan as
the fresh thread's first prompt.
- Covers the new popup option, event plumbing, initial-message behavior,
and disabled states in TUI tests.

## Problem

Plan Mode already asks whether to implement an approved plan, but the
only affirmative path continues in the same thread. That is useful when
the planning conversation itself is still valuable, but it does not
support the workflow where exploratory planning context is discarded and
implementation starts from the final approved plan as the only
model-visible handoff.

<img width="1253" height="869" alt="image"
src="https://github.com/user-attachments/assets/90023d75-c330-4919-bed8-518671c3474b"
/>

## Mental model

There are now two implementation choices after a proposed plan. The
existing choice, `Yes, implement this plan`, is unchanged: it switches
to Default mode and submits `Implement the plan.` in the current thread.
The new choice, `Yes, clear context and implement`, treats the proposed
plan as a handoff artifact. It clears the UI/session context through the
same thread-start source used by `/clear`, then submits an initial
prompt containing the approved plan after the fresh thread is
configured.

The important distinction is that the new path is not compaction. The
model receives a deliberate implementation prompt built from the
approved plan markdown, not a summary of the previous planning
transcript. Both implementation choices require the Default
collaboration preset to be available, so the popup does not offer a
coding handoff when the fresh thread would fall back to another mode.

## Non-goals

This change does not alter `/clear`, `/compact`, or the existing
same-context Plan Mode implementation option. It does not add protocol
surface area or app-server schema changes. It also does not carry the
previous transcript path or a generated planning summary into the new
model context.

## Tradeoffs

The fresh-context option relies on the approved plan being sufficiently
complete. That matches the Plan Mode contract, but it means vague plans
will produce weaker implementation starts than a compacted transcript
would. The upside is that rejected ideas, exploratory dead ends, and
planning corrections do not leak into the implementation turn.

The current implementation stores the latest proposed plan in
`ChatWidget` rather than deriving it from history cells at selection
time. This keeps the popup action simple and deterministic, but it makes
the cache lifecycle important: it must be reset when a new task starts
so an old plan cannot be submitted later.

## Architecture

The TUI stores the most recent completed proposed-plan markdown when a
plan item completes. The Plan Mode approval popup uses that cache to
enable the fresh-context option and to build a first-turn prompt that
instructs the model to implement the approved plan in a fresh context.

Selecting the new option emits a TUI-internal
`ClearUiAndSubmitUserMessage` event. `App` handles that event by reusing
the existing clear flow: clear terminal state, reset app UI state, start
a new app-server thread with `ThreadStartSource::Clear`, and attach a
replacement `ChatWidget` with an initial user message. The existing
initial-message suppression in `enqueue_primary_thread_session` ensures
the prompt is submitted only after the new session is configured and any
startup replay is rendered.

## Observability

The previous thread remains resumable through the existing clear-session
summary hint. There is no new telemetry or protocol event for this path,
so debugging should start at the TUI event boundary: confirm the popup
emitted `ClearUiAndSubmitUserMessage`, confirm the app-server thread
start used `ThreadStartSource::Clear`, then confirm the fresh widget
submitted the initial user message after `SessionConfigured`.

## Tests

The Plan Mode popup snapshots cover the new option and preserve the
original option as the first/default action. Unit coverage verifies the
original same-context option still emits `SubmitUserMessageWithMode`,
the new option emits `ClearUiAndSubmitUserMessage` with the approved
plan embedded verbatim, and the clear-context option is disabled when
Default mode is unavailable or no approved plan exists. The broader
`codex-tui` test package passes with the updated fresh-thread
initial-message plumbing.

2026-04-17 14:30:09 -03:00