[BUG] freezing UI

Open 💬 0 comments Opened Jun 20, 2026 by profstout

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?

Summary: Composer/thread locks up in Claude Desktop — input stops registering in an existing thread; new threads work fine. Restart and --disable-gpu do not fix it. Recurring over several days.

Environment:

OS: Windows
Claude Desktop installed package version: 1.14271.0.0 (per Windows package manager; in-app About screen may show a different public build number)
Feature: Cowork / Claude Desktop

Steps to reproduce:

Use an existing Claude Desktop thread for an extended session.
At some point, the composer (text input box) in that thread stops accepting typed input.
Switching to a brand-new thread: typing works normally.
Returning to the original thread: still locked.

What I tried:

Full app quit and restart — did not resolve it.
Full system reboot — did not resolve it.
Launching with GPU acceleration disabled (--disable-gpu) — did not resolve it.
Issue recurred again after the above steps, in a different thread.

What ruled out hardware/OS causes:

Other applications' text fields (e.g., Codex, other text boxes) remained fully usable throughout — keyboard, RAM, GPU, and Windows input system are not implicated.
New Claude Desktop threads accept typing normally; only previously-open/long-running threads lock up.

Impact: Recurring, multi-day issue. Forces workaround of abandoning stuck threads and starting new ones, or switching to claude.ai web version, to keep working.

Note: Have not cleared application data, to avoid losing the stuck thread's conversation history.

One-line repro tag for triage: "Composer frozen in one thread; new thread works; restart and --disable-gpu do not fix it."

What Should Happen?

Summary: Composer/thread locks up in Claude Desktop — input stops registering in an existing thread; new threads work fine. Restart and --disable-gpu do not fix it. Recurring over several days.

Environment:

OS: Windows
Claude Desktop installed package version: 1.14271.0.0 (per Windows package manager; in-app About screen may show a different public build number)
Feature: Cowork / Claude Desktop

Steps to reproduce:

Use an existing Claude Desktop thread for an extended session.
At some point, the composer (text input box) in that thread stops accepting typed input.
Switching to a brand-new thread: typing works normally.
Returning to the original thread: still locked.

What I tried:

Full app quit and restart — did not resolve it.
Full system reboot — did not resolve it.
Launching with GPU acceleration disabled (--disable-gpu) — did not resolve it.
Issue recurred again after the above steps, in a different thread.

What ruled out hardware/OS causes:

Other applications' text fields (e.g., Codex, other text boxes) remained fully usable throughout — keyboard, RAM, GPU, and Windows input system are not implicated.
New Claude Desktop threads accept typing normally; only previously-open/long-running threads lock up.

Impact: Recurring, multi-day issue. Forces workaround of abandoning stuck threads and starting new ones, or switching to claude.ai web version, to keep working.

Note: Have not cleared application data, to avoid losing the stuck thread's conversation history.

One-line repro tag for triage: "Composer frozen in one thread; new thread works; restart and --disable-gpu do not fix it."

Error Messages/Logs

Steps to Reproduce

Cannot reliably reproduce on demand — occurs intermittently during normal use. Pattern observed: use an existing Claude Desktop thread for an extended session; at some point (unpredictable timing), the composer stops accepting typed input in that thread. Switching to a new thread works immediately. Returning to the original thread, it's still locked. Has recurred multiple times over several days, in different threads, with no consistent trigger identified.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

n/A

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_

View original on GitHub ↗