In YOLO mode, when connecting to Burp, the MCP will show this prompt, causing the task to be interrupted and unable to run.

[Usernmae-1326546]

In YOLO mode, when connecting to Burp, the MCP will show this prompt, causing the task to be interrupted and unable to run.

[Hmbown]

Thanks @Usernmae-1326546, this is a good catch. In YOLO mode, an MCP connection prompt should not strand the run in a half-interactive state; either the trust decision needs to be pre-resolved or the prompt needs to degrade into a clear actionable error instead of interrupting the task.

I have not merged a fix for this yet. To make the next pass precise, could you share the Burp MCP entry from your mcp.json with any secrets removed, plus the exact command you used to launch CodeWhale? The screenshot is enough to keep this open as a real bug, and those details will help us tell whether the prompt is coming from MCP server trust, tool approval, or the Burp server process itself.

[Usernmae-1326546]

[Hmbown]

Thanks, the screenshots are enough to narrow this down. I can see the MCP entry is a local stdio Java proxy:

"command": "java",
"args": ["-jar", "D:\\tools\\burp\\burpsuite\\myuse\\mcp\\mcp-proxy.jar", "--sse-url", "http://127.0.0.1:9876"]

and the launch path is codewhale --yolo.

My current read from the code is that this is not the normal HTTP/SSE MCP url path that CodeWhale can preflight with its network policy. CodeWhale starts a local stdio process, and that proxy then connects to Burp’s local SSE endpoint. That would explain why YOLO tool auto-approval can still end up with a stranded turn if the proxy/server emits a startup or connection prompt inside the MCP session.

No merged fix yet, and I am not closing this through #2504. The next fix should make this path deterministic in YOLO: either pre-resolve/auto-handle local stdio proxy startup prompts when safe, or convert the connection prompt into a clear MCP server/tool error instead of letting turn dispatch hang. If you can paste the text log emitted around the prompt from ~/.codewhale/logs or ~/.deepseek/logs, that would help confirm whether it is coming from the Java proxy process or CodeWhale’s MCP session handling.

[Hmbown]

A diagnostic slice for this is now in the v0.8.50 harvest branch #2504.

The branch harvested @cyq1017's #2538 as 588e54f84, then added c81d1c272 for multiline-collapse and token-redaction coverage. When an MCP stdio server prints a prompt/banner instead of JSON-RPC, CodeWhale now includes a bounded, single-line, redacted preview in the parse error so the blocking server prompt is visible without leaking bearer tokens or API-key parameters.

Verified locally with:

• cargo test -p codewhale-tui --all-features --locked invalid_json_preview -- --nocapture
• cargo test -p codewhale-tui --all-features --locked call_method_invalid_json -- --nocapture
• cargo clippy -p codewhale-tui --all-targets --all-features --locked -- -D warnings

Live #2504 CI is green across Ubuntu, macOS, Windows, lint, version drift, CodeQL, mobile smoke, npm smoke, and GitGuardian.

Leaving this issue open for now because the harvested change improves diagnosis of the Burp/MCP prompt path; it does not silently answer or bypass the server-side confirmation prompt. Thanks @Usernmae-1326546 for the report.