Linux app (beta): hang sending new turn to VS Code-originated conversation

Resolved 💬 1 comment Opened Jun 30, 2026 by joelfarthing Closed Jul 1, 2026

Summary

On the native Claude Code Linux app (beta), sending a new message to a
conversation that originated in the VS Code extension hangs indefinitely —
the UI shows "thinking" forever, never responds, and surfaces no error.

The conversation's transcript revives and renders correctly (read-only history
works); only the new turn fails.

Repro

  1. Start a conversation in the VS Code extension.
  2. Open the native Linux app — the VS Code conversation appears as

archived/revivable and its transcript displays correctly.

  1. Send a new message to that conversation from the app.
  2. Result: infinite "thinking", no response, no error.

Asymmetry (diagnostic tell)

| Conversation origin | Revive + new turn from the app |
|---|---|
| Cloud | ✅ works |
| Native app → opened in VS Code | ✅ works |
| VS Code extension → opened in app | ❌ infinite "thinking" |

Cross-surface read works everywhere; only the app writing a new turn into a
VS-Code-extension-owned conversation
fails.

Suspected mechanism

Appears the app revives the persisted transcript without spinning up (or
re-binding to) a live backend session for that conversation, so a new turn is
dispatched with no live session to land on and hangs rather than erroring.

Note: the same VS-Code-originated session resumes and responds normally via the
CLI (claude --resume <id>), which builds a fresh live session from the same
transcript — pointing the failure at the app's revive path specifically.

Environment

  • claude-desktop (Linux beta): 1.17377.0
  • Claude Code app component: 2.1.187
  • claude CLI: 2.1.197
  • OS: Ubuntu (Linux 6.17)

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗