Frequent error: Turn stalled - no completion signal received. Pleasetry again.

[yahayao]

Description

When using yolo mode for operations, it freezes and becomes unresponsive, with a prompt below displaying Turn stalled - no completion signal received. Pleasetry again. After some time, sending continue still cannot resume the operation, and the prompt below shows Turn dispatch timed out; the engine may have stopped. Please try again. If you exit codewhale after the Turn stalled - no completion signal received. Pleasetry again.prompt appears and then use codewhale run --continue to restore the session, the failed turn disappears, and you can immediately start a new conversation turn, but will finally stop after some time due to the same reason.

Expected behavior

codewhale can normally worked

Environment

• OS: Windows 10
• codewhale version: 0.8.48
• Install method: pnpm
• codewhale doctor summary:

codewhale Doctor
==================

Version Information:
  codewhale-tui: 0.8.48 (7765f32cddac)
  rust: unknown

Updates:
  · current: v0.8.48
  ✓ latest: v0.8.48
    Already up to date.

Configuration:
  ✓ config.toml found at ~\.codewhale\config.toml
  workspace: D:\Desktop\Code\github\emule
  search_provider: duckduckgo (source: default; set [search] provider = "bing" | "tavily" | "bocha" to switch)

State Root:
  active: ~\.codewhale
  dual roots: ~\.codewhale (primary) + ~\.deepseek (legacy)

API Keys:
  ✓ deepseek: env=no, config=yes
  · nvidia-nim: env=no, config=no
  · openai: env=no, config=no
  · atlascloud: env=no, config=no
  · wanjie-ark: env=no, config=no
  · openrouter: env=no, config=no
  · xiaomi-mimo: env=no, config=no
  · novita: env=no, config=no
  · fireworks: env=no, config=no
  · siliconflow: env=no, config=no
  · moonshot: env=no, config=no
  · sglang: env=no, config=no
  · vllm: env=no, config=no
  · ollama: env=no, config=no
  · credential precedence: ~/.deepseek/config.toml, OS keyring, then env
  ✓ active provider key resolved from config.toml

API Connectivity:
  · provider: deepseek
  · base_url: https://api.deepseek.com/beta
  · model: deepseek-v4-pro
  · strict_tool_mode: disabled
  ✓ API connection successful

MCP Servers:
  ✓ MCP feature flag enabled
  · MCP config not found at ~\.deepseek\mcp.json
    Run `codewhale mcp init` or `codewhale setup --mcp`.

Skills:
  · local skills dir not found at D:\Desktop\Code\github\emule\skills
  · .agents skills dir not found at D:\Desktop\Code\github\emule\.agents\skills
  ✓ global .agents skills dir found at ~\.agents\skills (2 items)
  ✓ global skills dir found at ~\.codewhale\skills (12 items)
  · selected skills dir: ~\.agents\skills

Tools:
  ✓ tools dir found at ~\.codewhale\tools (0 items)

Plugins:
  ✓ plugins dir found at ~\.codewhale\plugins (0 items)

Storage:
  ✓ tool-output spillover at ~\.deepseek\tool_outputs (115 files)
  · composer stash empty (Ctrl+S in the composer to park a draft)

Tool Dependencies:
  ✓ Python: python → code_execution tool registered
  ✓ Node.js: present → js_execution tool registered
  · pandoc: not found (optional)
    pandoc_convert tool is NOT advertised to the model. Install pandoc to enable:
      winget install JohnMacFarlane.Pandoc
  · tesseract: not found (optional)
    image_ocr tool is NOT advertised to the model. Install tesseract to enable:
      winget install UB-Mannheim.TesseractOCR
  · pdftotext: not found (optional — pure-Rust extractor is the default in v0.8.32)
    Install Poppler only if you want to opt into pdftotext for column-heavy PDFs.

Terminal Quirks:
  · no env-driven terminal-quirk overrides active

Platform:
  OS: windows
  Arch: x86_64
  ! sandbox not available (commands run best-effort)

All checks complete!

• Model/provider: deepseek
• Terminal app: windows terminal
• Shell: powershell

Logs, screenshots, or recordings

[AiurArtanis]

更新0.8.48之后我一天之内出现3次你说的情况了。退出后用codeWhale run --continue命令，恢复的会话是没有这次交流，但是看代码工程却又已经完成了一半😂

[yahayao]

更新0.8.48之后我一天之内出现3次你说的情况了。退出后用codeWhale run --continue命令，恢复的会话是没有这次交流，但是看代码工程却又已经完成了一半😂

我看着像deepseek api的问题，但是我也不确定

[carter-smalls]

Could be an Ai Api timeout problem. npx ai-doctor might catch missing timeout guards and unprotected requests.

[Hmbown]

Thanks everyone. I am treating this as the canonical stalled-turn / dispatch-timeout thread for the v0.8.48 Windows reports, and I am linking the duplicate reports #2496 and #2497 here so the evidence stays together. The extra note from #2497 about /context showing a hardcoded 128k max-token value is useful and should stay part of this investigation.

This is not closed yet. Current suspected areas are turn dispatch/liveness, Windows shell/tool execution, context-pressure handling, and provider/API timeout recovery; #2498 may address one Windows shell process-tree hang mode, but it does not yet explain all stalled-turn reports.

[aboimpinto]

I checked this against PR #2498.

I would not treat every report in this issue as proven to have the same root cause yet. #2487 is the broader stalled-turn / dispatch-timeout symptom thread, and there may still be separate provider/API timeout, context-pressure, or turn-dispatch liveness causes.

PR #2498 does match one concrete Windows shell/tool-execution failure mode that can surface with the same symptom: the immediate shell process exits, but a descendant process remains alive with inherited stdout/stderr pipe handles open. The shell output reader threads then never receive EOF, the turn completion path stalls, and the UI can end up showing the stalled-turn / dispatch-timeout messages.

PR #2498 is ready for harvest into v0.8.50 for that specific Windows shell process-tree hang mode:

• all CI checks are green, including Windows
• Greptile confidence is now 5/5
• review threads are resolved
• regression tests cover detached descendants, terminate-denied fallback, and kill-on-close behavior before reader-thread joins

Paulo Aboim Pinto

[Hmbown]

Thanks @aboimpinto, that matches the current release triage read. #2498 is now included in the draft v0.8.50 harvest PR #2504 as the Windows shell process-tree containment slice (cb4f660a2 + 382635e4a). That should address the concrete descendant-process/stdout-stderr handle leak mode you described.

I am keeping #2487 open as the canonical stalled-turn thread. The #2498 slice is one plausible Windows tool-execution root cause, but the broader reports can still involve provider/API timeout recovery, context pressure, or turn-dispatch liveness, so this should stay open until users can retest a v0.8.50 build and we have evidence that the remaining symptoms are gone or narrowed.