Initial public release of Warp.

Repo-Sync-Origin: warpdotdev/warp-internal@12af1d983b
This commit is contained in:
David Stern
2026-04-28 08:43:33 -05:00
commit 0dbd3d567a
4982 changed files with 1431549 additions and 0 deletions
+81
View File
@@ -0,0 +1,81 @@
# CLI Agent Composer Auto-Show & Auto-Dismiss Settings
## Summary
Add three new user-facing settings that control the automatic visibility of the CLI agent rich input composer. The first setting auto-hides the composer whenever a CLI agent is blocked (requiring direct keyboard interaction) and auto-shows it when the agent resumes work, gated on having the Warp plugin installed for rich status information. The second setting auto-opens the composer when a CLI agent session starts or a plugin listener is registered. The third setting controls whether the composer auto-dismisses after the user submits a prompt, applying whenever Setting 1 is not actively managing composer visibility (either because it is disabled or because there is no plugin listener).
A per-session `should_auto_toggle_input` flag tracks whether auto-toggle is active for a given session. Opening the composer (manually or automatically) opts the session in; manually dismissing (Escape, Ctrl-G toggle, footer button) opts it out. Auto-close on Blocked preserves the flag so auto-open can fire when the agent resumes.
## Problem
Today, users interacting with CLI agents (Claude, Codex, Gemini, etc.) must manually open the rich input composer via Ctrl-G or the footer button every time they want to send a message. There is no way to have the composer appear automatically when the agent is waiting for input. Similarly, after submitting a prompt, the composer remains open, which may not be desired for users who prefer a minimal terminal view when the agent is actively working.
## Goals
- Let users opt into auto-hiding the composer whenever a CLI agent enters a "blocked" state (requiring direct keyboard interaction), and auto-showing it when the agent resumes work, so the interaction feels seamless.
- Let users opt into auto-dismissing the composer after sending a prompt, reducing visual clutter when the agent is working.
- Gate the auto-show behavior on having rich conversation status (i.e., the Warp plugin listener is active), since without it we cannot reliably detect when the agent is blocked.
- Gate the auto-dismiss (post-submission) behavior on Setting 1 not actively managing visibility — when the plugin is present and Setting 1 is enabled, auto-show/hide handles visibility; otherwise the user can choose to have the composer close after submission.
## Non-goals
- Changing the existing manual Ctrl-G / footer button flows.
- Auto-installing the plugin or prompting for installation from these settings.
- Changing behavior in the regular agent conversation view (these settings apply only to CLI agent sessions).
## Figma / Design References
Figma: none provided
## User Experience
### Setting 1: "Auto show/hide composer based on agent status" (`auto_toggle_composer`)
- **Location**: Settings > AI > Coding Agents section, below existing "Show coding agent toolbar" toggle.
- **Label**: `Auto show/hide composer based on agent status`
- **Info tooltip** (ⓘ icon next to label): "Requires the Warp plugin for your coding agent"
- **Default**: `true` (on)
- **Behavior when enabled**:
- When a CLI agent session has a plugin listener (`session.listener.is_some()`), the session's `should_auto_toggle_input` flag is true, and the session status transitions to `Blocked` (permission request, idle prompt), the composer automatically closes (the agent requires direct keyboard interaction in the terminal).
- When the session status transitions away from `Blocked` (to `InProgress` or `Success`), the composer automatically opens.
- If the user manually dismisses the composer (Escape, Ctrl-G toggle, footer button), `should_auto_toggle_input` is set to `false` for that session, disabling auto-toggle until the composer is opened again.
- If there is no plugin listener on the session, this setting has no effect.
- **Behavior when disabled**: No automatic composer visibility changes based on status.
### Setting 2: "Auto open composer when a CLI agent session starts" (`auto_open_composer_on_cli_agent_start`)
- **Location**: Settings > AI > Coding Agents section, below Setting 1.
- **Label**: `Auto open composer when a CLI agent session starts`
- **Default**: `false` (off)
- **Behavior when enabled**:
- When a CLI agent session is created (command detection) or a plugin listener is registered, the composer automatically opens.
- Also sets the session's initial `should_auto_toggle_input` flag to `true`, enabling auto-toggle from Setting 1 immediately.
- **Behavior when disabled**: The composer does not auto-open on session start. The session's `should_auto_toggle_input` starts as `false`, so auto-toggle from Setting 1 remains dormant until the user manually opens the composer.
### Setting 3: "Auto dismiss composer after prompt submission" (`auto_dismiss_composer_after_submit`)
- **Location**: Settings > AI > Coding Agents section, directly below Setting 2.
- **Label**: `Auto dismiss composer after prompt submission`
- **Default**: `false` (off)
- **Behavior when enabled**:
- After the user submits a prompt through the CLI agent composer, the composer automatically closes.
- This setting is a no-op only when the plugin IS present, Setting 1 is enabled, AND `should_auto_toggle_input` is true (because Setting 1's status-driven logic manages visibility in that case). In all other scenarios (no plugin, or plugin present but Setting 1 disabled), this setting controls post-submission behavior.
- **Behavior when disabled**: The composer remains open after submission.
### Edge Cases
- **All settings enabled, plugin present**: Setting 1 governs visibility (auto-hide on blocked, auto-show on resume). Setting 2 auto-opens the composer on session start. Setting 3 is effectively a no-op because the plugin provides rich status.
- **All settings enabled, no plugin**: Setting 2 has no effect (requires plugin for reliable status). Setting 3 closes the composer after submission. Setting 1 has no effect (no rich status to react to).
- **Settings 1 on, Setting 2 off, plugin present**: Auto-toggle is enabled but dormant until the user manually opens the composer (which sets `should_auto_toggle_input = true`). After that, auto-hide on blocked and auto-open on resume are active.
- **Session ends while composer is open**: Existing behavior already handles this (composer closes when session is removed).
- **User manually dismisses composer**: `should_auto_toggle_input` is set to `false`, disabling auto-toggle for that session. The user must re-open the composer to re-enable it.
- **Multiple terminals with different CLI agents**: Settings are global; auto-show/hide applies per-terminal based on each terminal's session state and its own `should_auto_toggle_input` flag.
## Success Criteria
1. A new "Auto show/hide composer based on agent status" toggle appears in Settings > AI > Coding Agents with an (ⓘ) tooltip reading "Requires the Warp plugin for your coding agent". Defaults to on.
2. When enabled and the plugin is present, the composer closes automatically when the CLI agent enters a blocked state and opens when it resumes (once `should_auto_toggle_input` is true for the session).
3. A new "Auto open composer when a CLI agent session starts" toggle appears below the first setting. Defaults to off.
4. A new "Auto dismiss composer after prompt submission" toggle appears below the second setting. Defaults to off.
5. When enabled and no plugin is present, the auto-dismiss setting closes the composer after the user submits a prompt.
6. When the plugin IS present and auto-toggle is active, the auto-dismiss setting has no observable effect (auto-show/hide from setting 1 takes precedence).
7. All three settings persist via the standard settings infrastructure (cloud-synced).
8. All three settings are only effective when AI is enabled and the coding agent toolbar is enabled.
## Validation
- Manual testing: Enable each setting independently and in combination, with and without the Warp plugin, to verify correct auto-show/hide behavior.
- Unit tests: Verify that `CLIAgentSessionsModel` status transitions trigger the correct open/close calls when settings are enabled.
- Settings persistence: Verify settings survive app restart and cloud sync.
## Open Questions
- Should there be a brief delay before auto-showing the composer to avoid flicker for very brief blocked states? (Recommend: no delay initially, iterate if needed.)
+112
View File
@@ -0,0 +1,112 @@
# CLI Agent Composer Auto-Show & Auto-Dismiss — Tech Spec
## Problem
The PRODUCT.md spec requires three new settings that control the visibility lifecycle of the CLI agent rich input composer. The implementation spans settings definitions, the settings UI, the session model, and the terminal view's subscription to CLI agent session status changes.
## Relevant Code
- `app/src/settings/ai.rs (4921144)``AISettings` group where new settings will be added, near the existing `should_render_cli_agent_footer` setting.
- `app/src/settings_view/ai_page.rs (49495067)``CLIAgentWidget` that renders the "Coding Agents" section in Settings > AI.
- `app/src/terminal/cli_agent_sessions/mod.rs``CLIAgentSessionsModel` singleton, `CLIAgentSession`, `CLIAgentSessionStatus`, `CLIAgentInputState`.
- `app/src/terminal/view.rs:10802``handle_cli_agent_sessions_event()` which reacts to `CLIAgentSessionsModelEvent::StatusChanged`.
- `app/src/terminal/view/use_agent_footer/mod.rs:486524``submit_cli_agent_rich_input()` which currently always closes the composer after submission.
- `app/src/terminal/view/use_agent_footer/mod.rs:527574``open_cli_agent_rich_input()` which opens the composer.
## Current State
- The composer is opened manually via Ctrl-G or the footer button (`open_cli_agent_rich_input`).
- After the user submits a prompt, `submit_cli_agent_rich_input` always calls `close_cli_agent_rich_input`.
- `handle_cli_agent_sessions_event` only handles `StatusChanged` for desktop notifications when the user is navigated away — it does not drive any composer visibility logic.
- The `CLIAgentSession` struct has a `listener: Option<ModelHandle<CLIAgentSessionListener>>` field that indicates whether the plugin is connected.
## Proposed Changes
### 1. New settings in `AISettings` (`settings/ai.rs`)
Add three new boolean settings inside the `define_settings_group!(AISettings, ...)` block, placed after `should_render_cli_agent_footer`:
- `auto_toggle_composer` (`AutoToggleComposer`): default `true`. Auto-hides the composer on `Blocked` and auto-shows on `InProgress`/`Success`, gated on plugin presence and the per-session `should_auto_toggle_input` flag.
- `auto_open_composer_on_cli_agent_start` (`AutoOpenComposerOnCLIAgentStart`): default `false`. Auto-opens the composer when a session is created or a plugin listener is registered. Also sets the session's initial `should_auto_toggle_input` flag.
- `auto_dismiss_composer_after_submit` (`AutoDismissComposerAfterSubmit`): default `false`. Auto-closes the composer after prompt submission, only when Setting 1 is not actively managing visibility.
### 2. Settings UI (`settings_view/ai_page.rs`)
Extend `CLIAgentWidget` to include two new `SwitchStateHandle` fields and render two new toggles inside the "Coding Agents" section, gated on `is_footer_enabled`:
- **Setting 1 toggle**: Label "Auto show/hide composer based on agent status" with an `AdditionalInfo` info tooltip saying "Requires the Warp plugin for your coding agent".
- **Setting 2 toggle**: Label "Auto dismiss composer after prompt submission" with a description explaining the behavior.
Add corresponding `AISettingsPageAction` variants (`ToggleAutoToggleComposer`, `ToggleAutoDismissComposerAfterSubmit`) and wire them to the settings.
### 3. Per-session `should_auto_toggle_input` flag (`cli_agent_sessions/mod.rs`)
Add a `should_auto_toggle_input: bool` field to `CLIAgentSession`. This flag controls whether auto-toggle is active for a given session:
- Initialized from `*AISettings::as_ref(ctx).auto_open_composer_on_cli_agent_start` when the session is created or a listener is registered.
- Set to `true` whenever the composer is opened (via `open_input`, which always passes `true`).
- Set to `false` when the user manually dismisses the composer (`close_cli_agent_rich_input_and_disable_auto_toggle``close_input` with `false`).
- Preserved as `true` when auto-close fires on Blocked (`close_cli_agent_rich_input``close_input` with `true`).
Threaded through `register_listener`, `open_input`, and `close_input` as a parameter.
### 4. Auto-show/hide on status changes (`terminal/view.rs`)
Extend `handle_cli_agent_sessions_event` to react to `StatusChanged` for the current terminal view (not just notifications). When all conditions are met:
- `auto_toggle_composer` is enabled
- The session has a plugin listener and `should_auto_toggle_input` is `true`
- AI is enabled and the CLI agent toolbar is enabled
Then:
- On transition to `Blocked`: call `close_cli_agent_rich_input` (preserves `should_auto_toggle_input = true`).
- On transition to `InProgress` or `Success`: call `open_cli_agent_rich_input(AutoShow)` if the composer isn't already open.
Additionally, `maybe_auto_open_cli_agent_composer` is called after session creation and listener registration to handle the auto-open-on-start setting.
### 5. Conditional close after submission (`terminal/view/use_agent_footer/mod.rs`)
A shared `maybe_close_composer_after_submit` method encapsulates the conditional close logic, called from both the synchronous path and the `DelayedEnter` timer callback in `write_cli_agent_text_then_submit`. It checks `has_plugin` (plugin present AND `should_auto_toggle_input`) and `auto_toggle_composer` to decide whether status events manage visibility or `auto_dismiss_composer_after_submit` should close the composer.
### 6. Close variants (`terminal/view/use_agent_footer/mod.rs`)
- `close_cli_agent_rich_input`: delegates to `close_cli_agent_rich_input_impl(true)` — preserves `should_auto_toggle_input` for auto-close on Blocked.
- `close_cli_agent_rich_input_and_disable_auto_toggle`: delegates to `close_cli_agent_rich_input_impl(false)` — disables auto-toggle when the user manually dismisses.
All manual close call sites (Escape, Ctrl-G toggle, footer button toggle, footer hide, block completion) use the `_and_disable_auto_toggle` variant.
### 7. New `CLIAgentInputEntrypoint::AutoShow` variant
Added to `cli_agent_sessions/mod.rs` to distinguish auto-opens from manual opens in telemetry.
## End-to-End Flow
### Auto-open on session start (Setting 2 enabled):
1. CLI agent command detected → session created with `should_auto_toggle_input = true`.
2. `maybe_auto_open_cli_agent_composer` fires → composer opens via `AutoShow` entrypoint.
### Auto-hide on blocked, auto-show on resume (Setting 1 enabled, plugin present):
1. CLI agent runs and enters `PermissionRequest``CLIAgentSession::apply_event` sets status to `Blocked`.
2. `CLIAgentSessionsModel` emits `StatusChanged { status: Blocked }`.
3. `TerminalView::handle_cli_agent_sessions_event` checks: setting on, plugin present, `should_auto_toggle_input` true → calls `close_cli_agent_rich_input` (preserves flag).
4. User interacts directly with the terminal (e.g., approves permission).
5. Agent resumes → status changes to `InProgress` → handler calls `open_cli_agent_rich_input(AutoShow)`.
### Manual dismiss breaks auto-toggle cycle:
1. During auto-toggle, user presses Escape → `close_cli_agent_rich_input_and_disable_auto_toggle` sets `should_auto_toggle_input = false`.
2. Subsequent status changes no longer trigger auto-open/close for this session.
3. User manually re-opens with Ctrl-G → `open_input` sets `should_auto_toggle_input = true` → auto-toggle resumes.
### Auto-dismiss on submit (Setting 3 enabled, no plugin):
1. User manually opens composer with Ctrl-G.
2. User submits text → `maybe_close_composer_after_submit` checks: no plugin (or `should_auto_toggle_input` false), setting 3 is on → closes the composer.
## Risks and Mitigations
- **Flicker from rapid status transitions**: If a CLI agent rapidly transitions Blocked→InProgress→Blocked, the composer could flicker open/close. Mitigation: unlikely in practice since permission requests have user-gated responses. Can add a debounce later if needed.
- **Race with manual open**: If the user manually opens the composer just before auto-close fires, it could feel jarring. Mitigation: the auto-close only fires on status transitions, not on a timer, so it maps to genuine agent state.
## Testing and Validation
- Add unit tests in `cli_agent_sessions/mod_tests.rs` verifying that `StatusChanged` events propagate correctly.
- Add integration test scenarios exercising auto-show on blocked and auto-dismiss on submit.
- Manual testing with and without the plugin to verify both settings behave correctly.
## Follow-ups
- Add telemetry for auto-show/auto-dismiss to track adoption.
- Consider debounce/delay on auto-show if rapid transitions prove to be an issue.