Handle CLI agent needs-input in unattended runs - #16232
sohumgaitonde wants to merge 3 commits into
Conversation
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>
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>
|
Your Warp account is not a member of any team with access to this repository. |
|
Your GitHub account is not connected to Warp. Connect it here. |
|
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 Powered by Oz |
There was a problem hiding this comment.
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.mddid 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
|
Your GitHub account is not connected to Warp. Connect it here. |
|
Your Warp account is not a member of any team with access to this repository. |
seemeroland
left a comment
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
Can we add this as a bool field to ShutdownRequested?
| CLIAgentEventType::Unknown(_) => return None, | ||
| }; | ||
|
|
||
| self.session_context.blocked_on_needs_input = |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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
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_inputnotification, but Warp ignored the event, so the task stayedInProgressand nothing ever ended the run. There is also no safe way to shut such a run down today. The exit sequence types/exitand 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.
agent_needs_inputevent (the associated plugin change to send this is in flight) as a newCLIAgentEventType::NeedsInput.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.NeedsInput, skip the typed/exitand follow-up Enter and go straight to the existing safe force-kill. Other statuses keep the graceful exit ladder. A newblocked_on_needs_inputmarker on the session context lets the driver tell this case apart from ordinary permission or question blocks.The final reported state stays
BLOCKED. The existingidle_on_completewindow still applies, so runs the server launches with it get the usual recovery period.This depends on
claude-code-warpforwarding the event (idle_prompt|agent_needs_inputNotification 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_VERSIONis intentionally not bumped here.Testing
Unit tests added for:
agent_needs_inputintoNeedsInputBlockedmapping with the event summary, the generic fallback, and theblocked_on_needs_inputmarkerRan 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 warningscargo fmt --all -- --checkI have manually tested my changes locally with
./script/runAgent Mode
Co-Authored-By: Warp agent@warp.dev