[BUG] Research/Cowork mode: "API connection timeout" despite healthy session completion - local_ session IDs causing UUID validation errors

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Description:

When using Research/Cowork mode, requests hang at "starting request..." for ~3 minutes before showing "API connection timeout", even though the backend logs show the session completed successfully with cycle_health: 'healthy'.

Environment:

Claude Desktop: 1.1.799
Claude Code SDK: 2.1.15
macOS: 26.2.0 (Darwin 25.2.0)
Apple M3 Pro
Symptoms:

UI shows "starting request..." then times out after ~3 minutes
Backend logs show cycle_health: 'healthy' and had_first_response: true
Process exits cleanly with exit_code: 0
Root cause (from logs):

UUID validation errors - Local session IDs (prefixed with local_) appear to be sent to the web API, causing validation failures:

[REACT_QUERY_CLIENT] QueryClient error: Error: path.conversation_uuid: Input should be a valid UUID, invalid character: expected an optional prefix of urn:uuid: followed by [0-9a-fA-F-], found l at 1

CSP blocking API endpoint:

Refused to connect to 'https://a-api.anthropic.com/v1/m' because it violates the following Content Security Policy directive: "connect-src 'self' https://api.segment.io..."

Multiple React hydration errors (#418) in the UI

Logs showing healthy backend but broken UI:

main.log shows success:

cycle_health: 'healthy',
had_first_response: true,
seconds_to_outcome: 178

But claude.ai-web.log shows errors:

[REACT_QUERY_CLIENT] QueryClient error: Error: path.conversation_uuid: Input should be a valid UUID...

Workaround:
None found. Clearing caches and resetting VM session data did not resolve the issue.

----from code research eval-
Interesting! The logs show the session actually completed successfully with cycle_health: 'healthy' and had_first_response: true. The process ran for ~178 seconds and exited cleanly (exit_code: 0).

But you're seeing "API connection timeout" in the UI. This is a discrepancy - the backend thinks it succeeded, but the UI is showing a timeout.

Let me check for the actual error:

Ran 2 commands
I found the issue. There are multiple problems in the logs:

Key findings:

CSP blocking API calls:

Refused to connect to 'https://a-api.anthropic.com/v1/m' because it violates the following Content Security Policy directive

React hydration errors (React error #418) - indicating UI state issues

UUID validation errors:

path.conversation_uuid: Input should be a valid UUID, invalid character: expected an optional prefix of urn:uuid: followed by [0-9a-fA-F-], found l at 1

This suggests local session IDs (starting with local_) are being incorrectly sent to the API.

This appears to be an app-level bug. The session logs show "healthy" completion, but the UI is experiencing issues.

Recommended fix - Full reset:

1. Quit Claude completely

killall Claude

2. Clear all caches and temporary data

rm -rf ~/Library/Caches/com.anthropic.claudefordesktop
rm -rf ~/Library/Application\ Support/Claude/Cache
rm -rf ~/Library/Application\ Support/Claude/GPUCache
rm -rf ~/Library/Application\ Support/Claude/Code\ Cache

3. Reset the VM session data

rm -rf ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle/sessiondata.img

4. Clear local agent mode sessions (this will lose conversation history)

rm -rf ~/Library/Application\ Support/Claude/local-agent-mode-sessions

5. Restart Claude

open -a Claude

If you don't want to lose conversation history, try just steps 1-3 first and see if that helps.

This looks like a bug in the Claude desktop app version 1.1.799 where local session IDs are being passed to the web API incorrectly. You may want to report this to Anthropic at https://github.com/anthropics/claude-code/issues

What Should Happen?

What should happen:

When you submit a prompt in Research/Cowork mode:

The prompt should be sent to the VM
The VM process should make an API request to Anthropic
The response should stream back to the UI
You should see Claude's response appear in the chat
What's actually happening:

The prompt is sent to the VM ✅
The VM process starts and runs ✅
The backend reports success (cycle_health: 'healthy') ✅
But the UI never receives/displays the response ❌
The UI shows "API connection timeout" after ~3 minutes
The disconnect:

The backend thinks everything worked, but the UI layer is broken. The local_ prefixed session IDs are being incorrectly passed to an API endpoint that expects standard UUIDs, causing the UI to fail to retrieve or display the response.

Add this to the bug report:

Expected behavior:

Prompt submission should display Claude's response within seconds
The response that the backend successfully generated should appear in the chat UI
Actual behavior:

UI shows "starting request..." indefinitely
After ~3 minutes, displays "API connection timeout"
Backend logs show the request completed successfully, but the response never reaches the UI
Session ID format mismatch (local_* vs UUID) appears to break the UI's ability to retrieve the response

Error Messages/Logs

Steps to Reproduce

Steps to reproduce:

Open Claude Desktop app (version 1.1.799)
Start a new conversation in Research/Cowork mode (the mode that uses the VM)
Enter any prompt (e.g., "Hello")
Observe the UI shows "starting request..."
Wait approximately 3 minutes
UI displays "API connection timeout" error
Expected result:
Claude's response appears within seconds

Actual result:

UI hangs on "starting request..." for ~3 minutes
"API connection timeout" error is displayed
Backend logs show cycle_health: 'healthy' and successful completion
claude.ai-web.log shows UUID validation errors for local_ prefixed session IDs

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

Not sure...

Claude Code Version

Claude Code SDK: 2.1.15 Claude Desktop App: 1.1.799

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_