[BUG] Code tab: fixed-framerate text rendering causes blank screen and unnecessary resource usage — should be event-driven

Resolved 💬 3 comments Opened Mar 27, 2026 by Rolhen Closed Apr 8, 2026

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?

The Code tab in claude.ai renders terminal output using a fixed-framerate loop (likely requestAnimationFrame or a setInterval-based polling mechanism) instead of event-driven DOM updates. This causes two problems:

  1. Blank/frozen screen on load — The Code tab opens but never renders any content. No spinner, no cursor, nothing. The CLI version (claude in terminal) works perfectly at the same time, confirming the backend/API is functional. Refreshing sometimes fixes it, sometimes doesn't.
  1. Unnecessary resource consumption — A polling-based renderer keeps burning CPU cycles even when idle (no input, no output). For a terminal emulator that receives discrete events (WebSocket messages, keystrokes), this is architecturally wasteful.

What Should Happen?

Event-driven rendering: WebSocket message arrives → DOM update triggers. No message → no render cycle. This would be both more efficient and more reliable, eliminating the blank-screen failure mode where the render loop loses sync with the underlying state.

Error Messages/Logs

Steps to Reproduce

  1. Open claude.ai
  2. Switch to the Code tab
  3. Type anything (e.g. "ey")
  4. Observe: message appears in input but no response rendering occurs — screen stays blank

<img width="899" height="746" alt="Image" src="https://github.com/user-attachments/assets/8eb0ec6f-c054-45e0-b491-935372aef114" />

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Platform: claude.ai Code tab (interface, not CLI)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Terminal.app (macOS)

Additional Information

The CLI version uses Ink (React for terminals) which is inherently event-driven. The browser wrapper appears to add a framerate-based rendering layer on top, which introduces a failure mode that doesn't exist in the CLI. Switching to event-driven updates (WS message → render) would align the browser implementation with the CLI's architecture and eliminate this class of bugs entirely.

Environment

  • OS: Windows (also observed blank screen on other platforms per related issues)
  • Browser: Chrome (latest)
  • Claude Plan: Pro
  • CLI works: Yes — claude in terminal runs fine
  • Chat tab works: Yes — only Code tab affected

Related Issues

  • #21764 (Code tab shows black screen on Windows)
  • #25136 (Cowork tab not showing)

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗