Claude full screen mode is not working

[suntimental]

Pre-submit Checks

• I have searched Warp bugs and there are no duplicates
• I have searched Warp known issues page and my issue is not there
• I have an issue with AI and have included the debugging ID (Optional, but helps expedite the AI quality fix). Debugging ID instructions
• I have technical issue and have included the logs (optional, but helps expedite the bug fix). Log instructions

Describe the bug

New Claude CLI full screen mode is not working in warp. After switching to that mode it is not possible to input text.

To reproduce

1. Open Warp.
2. Open Claude on separate pane.
3. Switch Claude to full screen mode.
4. Try to input something.

Expected behavior

Claude CLI input is working in full screen mode.

Screenshots, videos, and logs

No response

Operating system (OS)

Windows

Operating system and version

26200.8737

Shell Version

No response

Current Warp version

No response

Regression

No, this bug or issue has existed throughout my experience using Warp

Recent working Warp date

No response

Additional context

It was checked that Claude full screen mode is working when Claude is working in windows terminal on the same machine.

Does this block you from using Warp daily?

No

Is this an issue only in Warp?

Yes, I confirmed that this only happens in Warp, not other terminals.

Warp Internal (ignore): linear-label:b9d78064-c89e-4973-b153-5178a31ee54e

None

[oz-for-oss]

@suntimental

Here's what I found while triaging this issue:

Claude Code fullscreen rendering uses the terminal's alternate screen, so this looks like an alternate-screen input/focus issue rather than a normal shell prompt issue. As a temporary workaround, switching Claude Code back with /tui default or starting it with CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 should avoid that fullscreen renderer while this is investigated.

I have a few follow-up questions before I can narrow this down:

1. Can you attach a short screen recording showing the moment you switch Claude Code to fullscreen and then try typing in Warp?
2. Which exact Warp version/channel and Claude Code version are you using?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that claude Code fullscreen rendering on Windows appears to stop accepting input in Warp after entering the alternate-screen UI..

Triage summary

This looks like a Windows-specific terminal input bug involving Claude Code's fullscreen renderer in Warp. The reporter can reproduce after opening Claude in a separate pane, switching Claude to fullscreen mode, and then attempting to type; they also state the same flow works in Windows Terminal on the same machine.

Evidence and likely area

• Claude Code's fullscreen renderer is documented as an alternate-screen UI, similar to vim or htop, rather than a window-maximize feature.
• Warp's terminal view switches the normal input box to InputState::Disabled when entering alt-screen mode and routes keyboard events through AltScreenElement.
• AltScreenElement forwards key events only when the terminal view is focused, then converts keys through the terminal escape-sequence path, including Kitty keyboard protocol handling when enabled.
• On Windows, the initial key event conversion comes from the winit event-loop path before reaching the terminal escape-sequence layer.

Most relevant code areas are app/src/terminal/view.rs, app/src/terminal/alt_screen/alt_screen_element.rs, app/src/terminal/input.rs, crates/warp_terminal/src/model/escape_sequences/kitty_keyboard_protocol.rs, and crates/warpui/src/windowing/winit/event_loop/key_events.rs.

Reproducibility

Reproducibility is medium: the steps are concise and the reporter compared against Windows Terminal, but the issue is still missing exact Warp and Claude Code versions plus visual evidence of the focus/cursor state after entering fullscreen.

Duplicate check

I did not find two or more existing open or recently closed issues with the same combination of Claude Code fullscreen mode, Windows, and all text input failing in Warp. Nearby issues involve different surfaces, such as macOS Kitty shortcut encoding, Linux focus loss, or Windows RDP keyboard input.

Question reasoning

1. Can you attach a short screen recording showing the moment you switch Claude Code to fullscreen and then try typing in Warp? — The symptom is interactive and focus-sensitive; visual evidence would show whether the cursor/focus changes, whether keystrokes appear anywhere, and whether clicking the pane restores input.
2. Which exact Warp version/channel and Claude Code version are you using? — Both Warp's alt-screen input path and Claude Code's fullscreen renderer are version-sensitive, and the report omitted both versions.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[suntimental]

It strange, but after some clicks it start working. Suggesting to double check.

[oz-for-oss]

@suntimental

Here's what I found while triaging this issue:

This appears Warp-specific because the same Claude CLI fullscreen flow works in Windows Terminal on the same machine. The note that input can start working after some clicks suggests a focus/input handoff issue rather than Claude being completely hung.

I have a few follow-up questions before I can narrow this down:

1. Can you attach a short screen recording showing the switch into Claude fullscreen mode, the failed typing attempt, and the clicks that make input start working?
2. Which exact Warp version and channel are you running?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that claude CLI fullscreen mode on Windows stops accepting input in Warp until focus/click interaction recovers it..

Triage summary

The observed symptom is that Claude CLI's fullscreen/TUI mode on Windows stops accepting typed input in Warp, while the same Claude session works in Windows Terminal. The reporter later added that clicking around can make input start working, which makes this look more like a Warp focus/input-routing problem than Claude being completely stuck.

Repro confidence is medium: the report includes a plausible four-step repro and a same-machine comparison against Windows Terminal, but it is missing the Warp version/channel, shell, and visual evidence, and the behavior may be intermittent because clicks can recover it.

Likely implementation area: alternate-screen terminal input. In the current code, TerminalView::render switches to render_alt_screen_element when model.is_alt_screen_active() and is_input_box_visible hides the normal input for active alt-screen commands. ModelEvent::TerminalModeSwapped emits InputState::Disabled for alt screen transitions, while AltScreenElement forwards TypedCharacters/KeyDown only when is_terminal_focused; its left-click handler dispatches TerminalAction::Focus. That lines up with the reporter's note that clicking can make input start working.

Relevant files inspected:

• app/src/terminal/alt_screen/alt_screen_element.rs
• app/src/terminal/view.rs
• app/src/terminal/input.rs
• app/src/terminal/writeable_pty/pty_controller.rs

Duplicate check: I enumerated open issues and recent closed issues. Related reports exist for Claude/TUI keyboard behavior, such as #9159 and #12989, but they cover different shortcut-specific failures rather than the same Windows fullscreen no-input/focus recovery symptom, and fewer than two likely duplicates were found.

Question reasoning

1. Can you attach a short screen recording showing the switch into Claude fullscreen mode, the failed typing attempt, and the clicks that make input start working? — This is a visual/focus-sensitive terminal-input issue, and a recording would show whether focus remains on Warp's input area, the alt-screen grid, or another pane when typing is lost.
2. Which exact Warp version and channel are you running? — The report does not include a Warp version, and Windows terminal-input/alt-screen behavior can vary by release; the version is needed to correlate with recent fixes or regressions.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[suntimental]

Bug is reproduce in following case.

1. Open Warp.
2. Run Claude CLI in non fullscreen mode on new panel.
3. Run /tui fullscreen in claude.

Input in claude is not responsible.

[oz-for-oss]

@suntimental

Here's what I found while triaging this issue:

Thanks for the extra repro. Since the same Claude fullscreen flow works in Windows Terminal on the same machine, this appears likely to be Warp-specific input/focus handling for Claude CLI fullscreen mode.

I have a few follow-up questions before I can narrow this down:

1. Can you attach a short screen recording showing the /tui fullscreen transition and what happens when you type immediately afterward?
2. What Warp version and channel are you using when this reproduces?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that claude CLI /tui fullscreen on Windows appears to leave text input unavailable in Warp, likely through Warp's alt-screen and CLI-agent input focus routing..

Triage summary

This looks like a Warp-specific Windows bug affecting Claude CLI's fullscreen TUI mode. The reporter can reproduce by opening Warp, running Claude CLI in a separate pane, running /tui fullscreen, and then attempting to type; they also report the same Claude fullscreen mode works in Windows Terminal on the same machine.

The most likely area is terminal focus/input routing while a CLI-agent session is active in the alternate screen. app/src/terminal/alt_screen/alt_screen_element.rs only dispatches KeyDown / TypedCharacters actions when the TerminalView is focused. app/src/terminal/view.rs decides whether focus belongs to the terminal or the input box, and it gives active CLI-agent rich input sessions a path to keep the input surface visible even when the terminal is in alt-screen mode. app/src/terminal/input.rs, app/src/terminal/input/cli_agent.rs, app/src/terminal/cli_agent_sessions/mod.rs, and app/src/terminal/view/init.rs are relevant for CLI-agent rich input state, input-mode focus, and keybinding contexts.

I checked open issues and recent closed issues for duplicates. There are related Claude/TUI/input reports such as #9365, #9159, #9573, and #9899, but I did not find two or more strong duplicates matching the specific Windows /tui fullscreen input-unavailable behavior, so I am not marking this as a duplicate.

Remaining ambiguity: we still need reporter evidence showing where focus/cursor goes after switching to fullscreen, plus the Warp version/channel, before this is ready to implement confidently.

Question reasoning

1. Can you attach a short screen recording showing the /tui fullscreen transition and what happens when you type immediately afterward? — The symptom is visual/focus-related, and a recording would show whether focus remains in Warp's input surface, whether the Claude cursor moves, and whether clicks change the state.
2. What Warp version and channel are you using when this reproduces? — The report does not include the Warp build, and this determines whether maintainers should look for a current regression or an issue already fixed in a newer channel.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz