Repository navigation
Handle CLI agent needs-input in unattended runs - #16232
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 |
![warp-for-oss[bot]](https://avatars.githubusercontent.com/in/3450139?s=60&v=4){kind=small}
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
seemeroland
left a comment
There was a problem hiding this comment.
Approving to unblock, thanks!
- Carry the awaiting-input signal as a bool on ExitEscalationEvent::ShutdownRequested instead of a separate variant. - Record why a session is blocked on CLIAgentSessionStatus::Blocked via a BlockedSource enum, replacing the blocked_on_needs_input flag on the session context. Co-Authored-By: Warp <agent@warp.dev>
Co-Authored-By: Warp <agent@warp.dev>
|
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. |
|
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. |
1 similar comment
|
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. |
|
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. |
2 participants
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. TheBlockedstatus now records its source (BlockedSource: permission request, question asked, or needs-input), which 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 theNeedsInputblocked sourceRan targeted checks per
AGENTS.md:cargo nextest run -p warp --lib -E 'test(cli_agent_sessions) | test(exit_escalation) | test(plugin_manager) | test(local_agent_task_sync_model)'(231 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