Skip to content

Handle CLI agent needs-input in unattended runs - #16232

Open
sohumgaitonde wants to merge 3 commits into
masterfrom
sohum/handle-cli-needs-input
Open

sohumgaitonde wants to merge 3 commits into
masterfrom
sohum/handle-cli-needs-input

Conversation

@sohumgaitonde

@sohumgaitonde sohumgaitonde commented Oct 1, 2026 •

Copy link
Copy Markdown

Description

Unattended CLI agent runs (Oz cloud runs and the daemon) can hang indefinitely when the agent stops on a dialog that only a user can answer. Claude Code reports this through its agent_needs_input notification, but Warp ignored the event, so the task stayed InProgress and nothing ever ended the run. There is also no safe way to shut such a run down today. The exit sequence types /exit and Enter, and Enter answers whatever dialog is open, which can be a consent prompt we should never accept on the user's behalf.

This change makes those runs end predictably, using the existing blocked-run handling rather than anything specific to a particular dialog.

  • Parse the agent_needs_input event (the associated plugin change to send this is in flight) as a new CLIAgentEventType::NeedsInput.
  • In autonomous execution modes only (SDK and daemon), map it to Blocked, using the notification text as the status message and falling back to a generic message when there is none. The plugin caps the text length. The desktop app and TUI keep ignoring the event, so interactive behavior is unchanged.
  • When shutdown is requested for a session blocked on NeedsInput, skip the typed /exit and follow-up Enter and go straight to the existing safe force-kill. Other statuses keep the graceful exit ladder. A new blocked_on_needs_input marker on the session context lets the driver tell this case apart from ordinary permission or question blocks.

The final reported state stays BLOCKED. The existing idle_on_complete window still applies, so runs the server launches with it get the usual recovery period.

This depends on claude-code-warp forwarding the event (idle_prompt|agent_needs_input Notification matcher, plugin 2.3.0: warpdotdev/claude-code-warp#91). Until that plugin version is installed, the event never reaches Warp and this change has no effect. MINIMUM_PLUGIN_VERSION is intentionally not bumped here.

Testing

Unit tests added for:

  • parsing agent_needs_input into NeedsInput
  • the Blocked mapping with the event summary, the generic fallback, and the blocked_on_needs_input marker
  • other block types not setting the marker, and a later permission request clearing it
  • the autonomous-only gate (SDK applies the event, App mode ignores it)
  • the exit state machine skipping the typed exit and force-killing when blocked on needs-input

Ran targeted checks per AGENTS.md:

  • cargo nextest run -p warp --lib -E 'test(cli_agent_sessions) | test(exit_escalation) | test(plugin_manager)' (188 passed)

  • cargo clippy -p warp --all-targets --tests -- -D warnings

  • cargo fmt --all -- --check

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

Agent Mode

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

Co-Authored-By: Warp agent@warp.dev

Recognize the agent_needs_input CLI agent event as NeedsInput and, in
autonomous (CLI/daemon) execution modes only, report the session as
Blocked with a fixed message so the task is recorded as BLOCKED instead
of staying in progress. Interactive clients keep ignoring the event.

When the exit timer fires for a session blocked on NeedsInput, skip the
typed /exit and follow-up Enter, which would answer whatever prompt is
open, and go straight to the existing force-kill. Other statuses keep
the graceful exit ladder.

Co-Authored-By: Warp <agent@warp.dev>
@cla-bot cla-bot Bot added the cla-signed label Oct 1, 2026
Report the NeedsInput event's summary as the Blocked message, falling
back to the generic message when there is none, matching how
QuestionAsked is reported. The plugin bounds the summary length.

Co-Authored-By: Warp <agent@warp.dev>
@warp-agent-staging

Copy link
Copy Markdown
Contributor

Your Warp account is not a member of any team with access to this repository.

@warp-factories

warp-factories Bot commented Oct 1, 2026

Copy link
Copy Markdown
Contributor

Your GitHub account is not connected to Warp. Connect it here.

@sohumgaitonde
sohumgaitonde marked this pull request as ready for review October 1, 2026 20:17
@warp-for-oss

warp-for-oss Bot commented Oct 1, 2026 •

Copy link
Copy Markdown
Contributor

@sohumgaitonde

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 /warp-agent-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

@warp-for-oss warp-for-oss Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overview

Reviewed the PR that teaches CLI agent sessions to parse agent_needs_input, map it to a blocked state only for autonomous execution modes, track the needs-input marker on session context, and skip typed shutdown input before force-killing a harness that is already waiting on user input.

Concerns

  • No blocking correctness, security, test, comment-guideline, or spec-alignment concerns found. The added comments explain safety rationale or field semantics rather than restating implementation mechanics, and the targeted unit tests cover parsing, blocked-state mapping and fallback text, autonomous gating, marker clearing, Ctrl-C disarming, and the exit escalation path.
  • spec_context.md did not contain approved or repository spec commitments, so there was no material spec drift to flag.

Verdict

Found: 0 critical, 0 important, 0 suggestions

Approve

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

Powered by Oz

@warp-factories

warp-factories Bot commented Oct 1, 2026

Copy link
Copy Markdown
Contributor

Your GitHub account is not connected to Warp. Connect it here.

@warp-agent-staging

Copy link
Copy Markdown
Contributor

Your Warp account is not a member of any team with access to this repository.

@seemeroland seemeroland left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving to unblock, thanks!

/// CLI session reached a terminal state and asked the driver to stop the harness.
ShutdownRequested,
/// Same request, but the CLI session is blocked on user input.
ShutdownRequestedWhileAwaitingInput,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add this as a bool field to ShutdownRequested?

CLIAgentEventType::Unknown(_) => return None,
};

self.session_context.blocked_on_needs_input =

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather than store this on the session context, we could add a field to CLIAgentSessionStatus::Blocked since these are tightly coupled. It's probably nice to know the source of CLIAgentSessionStatus::Blocked on that message (could be an enum of the possible sources PermissionRequest, QuestionAsked, NeedsInput)

match escalation.on_event(start_event) {
ExitEscalationAction::SendExit => {}
ExitEscalationAction::ForceKillAndFinish => {
return Self::force_kill_and_report_timeout(harness_name, 1, foreground).await;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not blocking, but in this case it'd probably be better to try a graceful exit through SIGTERM first. In the general ladder case it'd be fine to try SIGTERM before SIGKILL as well

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants