Make BlocklistAiAinputModel surface agnostic by harryalbert · Pull Request #13333 · warpdotdev/warp

harryalbert · 2026-07-02T20:48:37Z

Description

BlocklistAIInputModel is shared between frontends, but its input-mode decisions were GUI-shaped: the initial config, the locked-AI gate, and the reactive transitions on conversation-selection and AI-settings events all consulted GUI-only state inline (FeatureFlag::AgentView, fullscreen-vs-terminal checks, CLIAgentSessionsModel). For the TUI this wasn't just untidy — it was incorrect: the gate silently no-oped the TUI's desired default ({AI, locked} with no active conversation), and the reactive writes could flip a TUI surface into {Shell, locked} (e.g. on conversation deactivation with NLD disabled), which the TUI would misread as user-requested shell mode. This PR extracts those decisions into a view-supplied InputModePolicy trait — following the same injection pattern as ConversationSelection — so the GUI and TUI each answer them for their own surface while the model keeps the shared mechanism.

The split is decisions-out, subscriptions-in: the model still owns the AISettings and ConversationSelection subscriptions (the ~35 GUI mutator call sites rely on the model self-healing across CLI-agent-input close and agent-view enter/exit), but each subscription now just forwards the raw event to the policy and applies the returned PolicyConfigUpdate — which bundles exactly what the previously-inlined GUI code passed to the internal setter: the config, its recorded decision source, and (for one agent-view entry path) a brief autodetection suppression. This is a pure refactor for the GUI: GuiInputModePolicy transplants each branch verbatim, and the existing input-mode test suites pass with no assertion changes.

This unblocks TUI input-mode work up-stack (specs/CODE-1805, TUI ! shell mode): TuiInputModePolicy starts locked to AI, always allows it, and never reacts to conversation or settings events — when TUI autodetection ships, that one file changes.

what to read

specs/input-mode-policy/TECH.md — the design doc; worth reading first.
app/src/ai/blocklist/input_mode_policy.rs — the new trait. Required methods are the five decision points the model can't make view-agnostically: initial config, the locked-AI gate, the autodetection setting for the surface's current context, and the two reactive hooks. The hooks receive the raw events, so view-specific payloads (fullscreen vs. inline, entry origins) stay a concern of the implementing view. The settings hook takes the model's guarded autodetection state as a bool; computing it takes the terminal-model lock, so the model only computes it for AIAutoDetectionEnabled events.
app/src/ai/blocklist/agent_view/gui_input_mode_policy.rs — the GUI policy: each method is the corresponding branch from master, moved verbatim. The FeatureFlag::AgentView checks become a GUI-policy detail instead of a model detail.
app/src/ai/blocklist/input_model.rs — the model after the extraction: subscriptions forward to the policy, the gate asks allows_locked_ai_input, and is_autodetection_enabled_for_current_context keeps only the view-agnostic guards (agent-in-control, pending attachments) layered over the policy's setting lookup. InputConfig::unlocked_if_autodetection_enabled is no longer called by the model.
app/src/ai/blocklist/input_model_tests.rs — new unit tests driving the model through a configurable StubPolicy: the initial config comes from the policy (a locked-AI initial sticks — the old gate would have rejected it), locked-AI writes require policy permission, and inert policies leave the config untouched across conversation and settings events.
crates/warp_tui/src/input_mode_policy.rs — the TUI policy: {AI, locked} initial, locked AI always allowed, no autodetection, both reactive hooks return None.

Testing

I have manually tested my changes locally with ./script/run

Screenshots / Videos

Nothing to show yet, but things continue to work as before.

Agent Mode

Warp Agent Mode - This PR was created via Warp's AI Agent Mode

harryalbert · 2026-07-02T20:48:59Z

This stack of pull requests is managed by Graphite. Learn more about stacking.

oz-for-oss · 2026-07-03T01:26:19Z

@harryalbert

I'm starting a first review of this pull request.

You can view the conversation on Warp.

I completed the review and no human review was requested for this pull request.

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

BlocklistAIInputModel consulted GUI-only state (FeatureFlag::AgentView, fullscreen-vs-terminal context, CLI agent sessions) directly in five places, which made the model unusable from the TUI frontend: the AI-lock gate silently rejects locked-AI configs and the reactive subscriptions rewrite the config based on GUI product rules. Following the ConversationSelection injection pattern, extract those decisions into a view-supplied InputModePolicy trait: - GuiInputModePolicy transplants the existing branches verbatim (no behavior change). - TuiInputModePolicy gives the TUI a deterministic agent-first config. See specs/input-mode-policy/TECH.md. Co-Authored-By: Oz <oz-agent@warp.dev>

oz-for-oss

Overview

This PR extracts BlocklistAIInputModel's surface-specific input-mode decisions into an injected InputModePolicy, wires GUI and TUI policy implementations, adds model-level tests, and includes a tech spec for the refactor.

Concerns

The PR changes user-facing TUI/input-mode behavior but the description does not include screenshots or a recording; repo guidance requires visual evidence for manually testable user-facing changes.
The added tech spec's validation section claims new warp_tui input-mode policy unit tests, but the diff only adds app/src/ai/blocklist/input_model_tests.rs; either add the promised TUI policy tests or correct the validation section.
spec_context.md reports no approved or repository spec context for this PR, so no external spec-drift concern was identified.

Verdict

Found: 0 critical, 1 important, 1 suggestions

Request changes

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

oz-for-oss · 2026-07-03T01:29:24Z

+
+impl InputModePolicy for TuiInputModePolicy {
+    fn initial_config(&self, _app: &AppContext) -> InputConfig {
+        InputConfig {


⚠️ [IMPORTANT] This changes the user-visible TUI default input mode, but the PR description has no screenshot or recording. Please attach visual evidence showing the TUI prompt starts in AI mode and the refactored input-mode flow works end to end.

oz-for-oss · 2026-07-03T01:29:24Z

+## Testing and validation
+
+- This is a no-behavior-change refactor for the GUI: `app/src/terminal/input_tests.rs` (~43 references) exercises every input-mode flow (⌘I toggle, `!` prefix, `&` handoff, ctrl-c reset, history selection, workflow insertion, attachment locking) through the real `Input` view and must pass with **no assertion changes**. Same for `app/src/terminal/view_tests.rs` and `queued_prompts_tests.rs`.
+- New `input_mode_policy` unit tests in `warp_tui` assert the TUI policy's determinism: initial `{AI, locked}` sticks (the old gate would have rejected it), and reactive hooks leave the config untouched across conversation activate/deactivate.


💡 [SUGGESTION] This validation item says new warp_tui input-mode policy unit tests were added, but the diff only adds app/src/ai/blocklist/input_model_tests.rs. Either add the promised TUI policy tests or update the validation section to match the actual coverage.

kevinyang372

Nice!

cla-bot Bot added the cla-signed label Jul 2, 2026

harryalbert force-pushed the harry/input-mode-policy branch 2 times, most recently from 1d3fc30 to ac50bee Compare July 2, 2026 22:46

harryalbert force-pushed the harry/code-1801-think-blocks branch from 5205fea to 63ad782 Compare July 2, 2026 22:46

harryalbert force-pushed the harry/input-mode-policy branch from ac50bee to 52658fc Compare July 2, 2026 22:54

harryalbert force-pushed the harry/code-1801-think-blocks branch from 8bb92ac to dd2d631 Compare July 2, 2026 22:55

harryalbert force-pushed the harry/input-mode-policy branch 2 times, most recently from bec8c91 to d0c2d95 Compare July 2, 2026 23:06

harryalbert force-pushed the harry/code-1801-think-blocks branch from dd2d631 to 2300f7c Compare July 2, 2026 23:06

harryalbert changed the base branch from harry/code-1801-think-blocks to graphite-base/13333 July 2, 2026 23:39

harryalbert force-pushed the harry/input-mode-policy branch from d0c2d95 to b140ab5 Compare July 2, 2026 23:42

harryalbert force-pushed the graphite-base/13333 branch from 2300f7c to 3fd1d55 Compare July 2, 2026 23:42

harryalbert changed the base branch from graphite-base/13333 to harry/code-1801-think-blocks July 2, 2026 23:42

Base automatically changed from harry/code-1801-think-blocks to master July 2, 2026 23:54

harryalbert force-pushed the harry/input-mode-policy branch from b140ab5 to 4ddf203 Compare July 3, 2026 00:13

harryalbert changed the title ~~refactor: extract InputModePolicy from BlocklistAIInputModel~~ Make BlocklistAiAinputModel surface agnostic Jul 3, 2026

harryalbert marked this pull request as ready for review July 3, 2026 01:26

harryalbert requested a review from kevinyang372 July 3, 2026 01:26

harryalbert and others added 2 commits July 2, 2026 21:26

clean up weird fn

4898f7e

harryalbert force-pushed the harry/input-mode-policy branch from 4ddf203 to 4898f7e Compare July 3, 2026 01:27

oz-for-oss Bot reviewed Jul 3, 2026

View reviewed changes

kevinyang372 approved these changes Jul 3, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Make BlocklistAiAinputModel surface agnostic#13333

Make BlocklistAiAinputModel surface agnostic#13333
harryalbert wants to merge 2 commits into
masterfrom
harry/input-mode-policy

harryalbert commented Jul 2, 2026 •

edited

Loading

Uh oh!

harryalbert commented Jul 2, 2026 •

edited

Loading

Uh oh!

oz-for-oss Bot commented Jul 3, 2026 •

edited

Loading

Uh oh!

oz-for-oss Bot left a comment

Uh oh!

oz-for-oss Bot Jul 3, 2026

Uh oh!

oz-for-oss Bot Jul 3, 2026

Uh oh!

kevinyang372 left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

harryalbert commented Jul 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

what to read

Testing

Screenshots / Videos

Agent Mode

Uh oh!

harryalbert commented Jul 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

oz-for-oss Bot commented Jul 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

oz-for-oss Bot left a comment

Choose a reason for hiding this comment

Overview

Concerns

Verdict

Uh oh!

oz-for-oss Bot Jul 3, 2026

Choose a reason for hiding this comment

Uh oh!

oz-for-oss Bot Jul 3, 2026

Choose a reason for hiding this comment

Uh oh!

kevinyang372 left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

harryalbert commented Jul 2, 2026 •

edited

Loading

harryalbert commented Jul 2, 2026 •

edited

Loading

oz-for-oss Bot commented Jul 3, 2026 •

edited

Loading