[BUG] /tui fullscreen ↔ /tui default toggling eventually makes the interactive session unresponsive (process stays alive, CPU-idle; no output ever resumes)

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?

Claude Code version: 2.1.228
OS: Windows 11

Summary

Repeatedly toggling /tui fullscreen and /tui default in an interactive session eventually leaves the
session completely unresponsive to further input. The underlying claude.exe process stays alive and
responsive at the OS level, with CPU usage flat/near-idle, but produces no further terminal output
and never recovers on its own.

Steps to reproduce

1. Launch Claude Code in a normal Windows terminal: claude.
2. Working directory does not appear to matter.
3. Toggle /tui fullscreen and /tui default back and forth repeatedly.
4. After some number of toggles, the interactive session stops responding to input (no visible

reaction to typed text or Enter).

Expected vs. actual behavior

• Expected: the session keeps responding to input and toggling between renderers indefinitely, or, if

a renderer switch fails, surfaces an error and returns to a working state.

• Actual: the session silently stops responding. No error is shown to the user. The process does not

exit or crash — it stays alive and idle.

Reproduction reliability

Reproduced on 4 out of 4 toggling attempts, across two independent environments:

• Twice inside a third-party ConPTY-based terminal-hosting application.
• Once in a plain Windows terminal running claude directly, with no wrapper of any kind.
• Once invoking the resolved claude.exe binary directly with an explicit --permission-mode default

flag.

No attempt at extended toggling failed to eventually reproduce the freeze.

Reproduces outside any third-party host

This was first noticed via a third-party application that hosts Claude Code in its own ConPTY-based
terminal. That application's own code was fully ruled out: the freeze was reproduced identically in a
plain Windows terminal, with claude launched directly and a fully inherited environment — no
third-party code, no custom PTY host, and no wrapper involved at all. The issue is not specific to
any particular terminal-hosting integration.

Process remains alive and CPU-idle during the freeze

Measured independently across three separate reproductions:

• Via the third-party host's own PTY handling plus independent OS-level process queries: observed

continuously for 5+ minutes. The process never reported as exited, by two independent checks. The
read call waiting on the process's output never returned. CPU time was completely flat (zero
measurable increase) for the entire 5+ minute window. Thread states were overwhelmingly idle/waiting.

• In a plain terminal: process remained responsive at the OS level; CPU time increased by ~0.05s over

a 10-second sample.

• Invoking the resolved binary directly: process remained responsive at the OS level; CPU time

increased by ~0.02s over a 10-second sample.

All three measurements are consistent with the process being alive and genuinely idle — not
deadlocked in a CPU-spinning loop, not crashed, and not exited.

--debug-file does not capture the frozen process

Claude Code relaunches itself into a child process during normal startup (observed via OS
process-tree inspection), and in one reproduction, into a further replacement process mid-session.
--debug-file <path> passed on the initial invocation only captures the outermost process's own
startup log — it does not propagate to the self-relaunched child, so it never covers the process that
actually becomes unresponsive. No supported mechanism for directing debug output to that process was
found in claude --help or in local settings.

A non-fatal CCRClient: Epoch mismatch (409, reason=unattributed) / bridge-teardown message was
observed in the outer process's log at the self-relaunch handoff, in more than one run. This is
reported only as a factual observation — it occurred well before the freeze in the run where timing
could be compared, and no causal relationship to the freeze has been established.

What is proven vs. unknown

Proven:

• The freeze reproduces independent of any third-party integration.
• The process that ends up frozen stays alive and CPU-idle for as long as observed (5+ minutes) — not

crashed, not exited, not busy-looping.

• Claude Code relaunches itself into a child process at least once during startup, and in one

observed case again mid-session.

• --debug-file does not produce diagnostics covering the process that becomes unresponsive.

Not established:

• Why the process goes idle and never resumes.
• Whether the CCRClient: Epoch mismatch (409) message is related to the freeze in any way.
• Whether the mid-session self-relaunch is a symptom, a failed recovery attempt, or unrelated.

No root cause is claimed — this report is limited to reproducible, independently-verified
observations to help narrow down the cause.

What Should Happen?

The /tui fullscreen ↔ /tui default commands should switch the renderer reliably and the Claude Code session should remain responsive to input. If a renderer switch cannot be completed, Claude Code should report the error and return to a working state rather than silently becoming unresponsive.

Error Messages/Logs

Steps to Reproduce

1. On Windows 11, open a normal Windows Terminal / PowerShell window.
2. Run claude in any working directory.
3. Once the interactive Claude Code session is running, repeatedly toggle:

/tui fullscreen
/tui default

1. Continue toggling for a few minutes.
2. Eventually, the session becomes unresponsive to further input. Typed text and Enter produce no visible response.
3. Wait several minutes. The claude.exe process remains alive, but the session does not recover.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.228

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_