[BUG] Chat can remain stuck on "API Request..." and stop sending after task/context switch

[edelauna]

Problem (one or two sentences)

After a task switch (or certain project-path/worktree context transitions), chat can stay in an API-request state and user messages stop sending. The input appears locked as if a request is still active.

Context (who is affected and when)

Seen by users in active coding sessions, especially when moving between task contexts (e.g., different project path/worktree or external/internal context switches). Impact is high because chat appears available but messages do not send.

Reproduction steps

1. Environment/setup: VS Code with Zoo Code extension, any provider/model (reported across multiple providers).
2. Start Task A and trigger a request so chat enters API Request... / streaming state.
3. Switch to a different task/context (Task B) without fully resetting session UI state.
4. Try to send a normal follow-up message in Task B.
5. Observe the message is not sent and chat remains effectively locked.

Expected result

After switching to a new task/context, chat input should re-enable and messages should send normally.

Actual result

Chat remains stuck in request/disabled state and new messages are not sent.

Variations tried (optional)

• Reproduced with different providers/models (community reports mention this across setups).
• Trigger seems correlated with context/task transitions rather than a single provider.

App Version

v3.55.x (reported; exact patch version unknown)

API Provider (optional)

Not Applicable / Other

Model Used (optional)

N/A

Zoo Code Task Links (optional)

N/A

Relevant logs or errors (optional)

Include UI/API history showing persistent api_req_started / locked send state after task switch.

[maxron84]

I have the same issue on my Windows 11 VM, on the other hand, it works fine on my Linux Bare Metal, two different machines. Zoo Code Debug and Output Logs do not indicate specific errors.

[proyectoauraorg]

Initial Investigation

After reviewing the task lifecycle code, here's my analysis:

Root Cause Hypothesis

The isStreaming flag in Task.ts controls the UI lock state. When a task is actively streaming (isStreaming = true), the UI disables the send button. The flag is reset to false in two places:

1. recursivelyMakeClineRequests finally block (line 3185) — normal completion
2. resumeAfterDelegation (line 2271) — after delegation returns

The problem: If a task switch occurs via a path that does NOT go through resumeAfterDelegation (e.g., worktree switch, external context change, or a race where the old task's stream hasn't fully cleaned up), isStreaming remains true on the Task object. When ClineProvider checks getCurrentTask()!.isStreaming (line 2925), it sees the stale true and keeps the UI locked.

Key Code Paths

• Task.ts:2271 — this.isStreaming = false in resumeAfterDelegation()
• Task.ts:3185 — this.isStreaming = false in finally block of streaming
• ClineProvider.ts:2925 — UI checks getCurrentTask()!.isStreaming === false

Windows-Specific Factor

The Windows-only reproduction (reported by maxron84) could relate to terminal process cleanup timing — ExecaTerminal on Windows has different signal handling that may delay the finally block execution.

Suggested Fix

Add isStreaming = false reset in the task abandonment/switch path, and consider a safety timeout in the webview that auto-resets the streaming state after N seconds of no chunks.

Next Steps

1. Confirm which task switch path does NOT call resumeAfterDelegation
2. Check if abortStream() properly resets isStreaming in all code paths
3. Reproduce on Windows to confirm terminal timing hypothesis

Will continue investigating and submit a PR with a fix.

[proyectoauraorg]

Merge Request — 3 PRs Ready

The following PRs are ready for merge and would unblock security fixes and critical bug fixes:

1. PR #383 — Ripgrep Fix (v3.55.1 release)

• Status: All checks pass, REVIEW_REQUIRED
• Impact: Closes [BUG] API request hangs indefinitely on VS Code 1.122.0+ due to renamed @vscode/ripgrep module #381 and [BUG] "Could not find ripgrep binary" on VS Code ≥1.122.0 due to @vscode/ripgrep → @vscode/ripgrep-universal rename #382 — all users on VS Code 1.122.0+ are affected
• Priority: 🔴 Critical — chat is completely broken for affected users

2. PR #387 — MCP SDK resource_link type fix

• Status: All checks pass, targets renovate/npm-modelcontextprotocol-sdk-vulnerability
• Impact: Unblocks PR fix(deps): update dependency @modelcontextprotocol/sdk to v1.26.0 [security] #351 (security dependency update)
• Priority: 🔴 High — blocks security dependency merge

3. PR #341 — tmp v0.2.6 security update

• Status: All checks pass, MERGEABLE
• Impact: Addresses security vulnerability in tmp dependency
• Priority: 🟡 Medium — security dependency

Requesting review from @taltas @hannesrudolph @JamesRobert20