Agent doesnt continue and stops

[PierrunoYT]

Pre-submit Checks

• I have searched Warp bugs and there are no duplicates
• I have searched Warp known issues page and my issue is not there
• I have an issue with AI and have included the debugging ID (Optional, but helps expedite the AI quality fix). Debugging ID instructions
• I have technical issue and have included the logs (optional, but helps expedite the bug fix). Log instructions

Describe the bug

The Agent says it will continue but then it stops and nothing happens

To reproduce

Use Qwen 3.7 Max via Openrouter

Expected behavior

Screenshots, videos, and logs

Operating system (OS)

Select an OS

Windows

Operating system and version

Windows 11 Pro

Shell Version

Current Warp version

No response

Regression

No, this bug or issue has existed throughout my experience using Warp

Recent working Warp date

No response

Additional context

No response

Does this block you from using Warp daily?

Yes, this issue prevents me from using Warp daily.

Is this an issue only in Warp?

Yes, I confirmed that this only happens in Warp, not other terminals.

Warp Internal (ignore): linear-label:b9d78064-c89e-4973-b153-5178a31ee54e

None

[oz-for-oss]

@PierrunoYT

Here's what I found while triaging this issue:

Thanks for the screenshot — this looks like an Agent/custom OpenRouter model continuation issue, but we need request-level diagnostics to determine whether the model/provider stream ended, errored, or the UI stopped rendering further output.

I have a few follow-up questions before I can narrow this down:

1. What Warp version and channel were you using when this screenshot was captured?
2. Can you attach the Agent debugging ID or conversation/debug link for the stopped turn shown in the screenshot?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that warp Agent appears to stop after a completed command when using the qwen/qwen3.7-max custom OpenRouter model on Windows, but the report needs request-level diagnostics to distinguish a model/provider stream issue from client UI or recovery behavior..

Triage summary

This looks like an Agent-mode bug involving a custom OpenRouter model on Windows. The screenshot shows qwen/qwen3.7-max (Custom · Openrouter) selected and an Agent turn that completed a PowerShell Remove-Item command, said it would verify the cleanup, then apparently produced no follow-up action.

Reproducibility

Low. There is useful visual evidence and a model/provider hint, but the report does not include the Warp version/channel, Agent debugging ID, logs, or a minimal prompt/task that maintainers can replay. The issue may depend on the reporter's custom endpoint configuration, OpenRouter/provider response behavior, account state, or a Windows-specific client state.

Duplicate check

I checked open issues across the repository plus recently closed issues. #7206 is broadly similar because it reports Agent stopping mid-task on Windows, and #11422 describes Windows Agent conversations where work may continue while chat rendering stops, but I did not find two close matches for the specific Qwen/OpenRouter custom-model continuation failure. I am not marking this as a duplicate.

Likely area

The relevant client paths are the custom model/provider request plumbing and multi-agent response-stream handling. The current client code builds synthetic custom model entries, sends configured custom endpoints with the agent request, and has retry/resume logic for recoverable stream errors after client actions. The available evidence is not enough to tell whether the stopped turn came from a provider/model stream ending unexpectedly, a non-recoverable backend error, or a Windows UI/conversation-state problem.

Question reasoning

1. What Warp version and channel were you using when this screenshot was captured? — The report provides Windows 11 Pro but not the Warp build; version/channel is needed to correlate this with recent Agent response-stream and custom endpoint behavior.
2. Can you attach the Agent debugging ID or conversation/debug link for the stopped turn shown in the screenshot? — The screenshot alone cannot show whether the multi-agent request finished normally, failed with a backend/provider error, or was truncated after the completed PowerShell command.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[PierrunoYT]

019eefbe-ba56-7aa1-bd72-94207640538a

v0.2026.06.17.09.49.stable_02.

[oz-for-oss]

@PierrunoYT

Here's what I found while triaging this issue:

The screenshot shows the command completed successfully and the agent then said it would verify the cleanup, but no follow-up verification step appears. This may be tied to the custom OpenRouter Qwen model path unless it also reproduces with Warp-provided models.

I have a few follow-up questions before I can narrow this down:

1. Does the same prompt stop after a successful command when you switch from qwen/qwen3.7-max via OpenRouter to a Warp-provided model?
2. Was this run local Agent Mode in the Windows PowerShell session shown in the screenshot, or was it sent to a cloud/remote agent?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that agent Mode appears to stop after a successful PowerShell action when using the custom OpenRouter Qwen model, but the report lacks enough run/session detail to determine whether this is model-provider-specific or a generic Agent continuation bug..

Triage summary

The report describes Agent Mode saying it will continue, then becoming idle. The attached screenshot shows a successful PowerShell Remove-Item action, followed by the assistant text "Let me verify they're gone now" with no visible verification command afterward. The run appears to use qwen/qwen3.7-max through a custom OpenRouter endpoint on Windows 11 Pro, and the triggering comment adds v0.2026.06.17.09.49.stable_02 plus what appears to be a debugging/session ID.

Current assessment

This is best routed as area:agent on Windows with needs-info and repro:low. The evidence points to a real Agent continuation/turn-completion issue, but the report is too narrow to distinguish a Warp client bug from model/provider behavior with a custom OpenRouter model.

Root-cause notes for maintainers

A low-confidence code-path hypothesis is that the model/provider returns a completed assistant response after text that implies another step, but without a follow-up tool/action call. In app/src/ai/blocklist/controller.rs, stream finish reasons of Done or None mark the response completed successfully. app/src/ai/blocklist/history_model.rs then marks the request complete, while app/src/ai/blocklist/action_model.rs only keeps driving the conversation when actions are queued/running or when status transitions back to in-progress. If the assistant says it will verify but no next action is emitted, the conversation can look like it stopped silently.

Relevant areas to inspect:

• app/src/ai/blocklist/controller.rs for response finish handling.
• app/src/ai/blocklist/history_model.rs for marking requests completed.
• app/src/ai/blocklist/action_model.rs for queued/running action status transitions.
• app/src/ai/agent/conversation.rs for conversation status semantics.
• app/src/ai/llms.rs for custom endpoint/model selection.

Duplicate check

No duplicate is being marked. Repository-wide open-issue enumeration found broad agent-stop issues such as #7206 and nearby but different reports like #7152 and #11422; however, provider/model-specific searches for OpenRouter/Qwen only returned this issue, and the other candidates do not share enough reproduction detail to satisfy the duplicate threshold.

Question reasoning

1. Does the same prompt stop after a successful command when you switch from qwen/qwen3.7-max via OpenRouter to a Warp-provided model? — This determines whether the bug is likely specific to the custom OpenRouter/Qwen model path or a general Agent continuation issue.
2. Was this run local Agent Mode in the Windows PowerShell session shown in the screenshot, or was it sent to a cloud/remote agent? — The execution mode changes the owner and code path; the screenshot suggests a Windows PowerShell session but does not conclusively identify local vs cloud/remote execution.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz