[BUG] Code tab: fixed-framerate text rendering causes blank screen and unnecessary resource usage — should be event-driven
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:
- Blank/frozen screen on load — The Code tab opens but never renders any content. No spinner, no cursor, nothing. The CLI version (
claudein terminal) works perfectly at the same time, confirming the backend/API is functional. Refreshing sometimes fixes it, sometimes doesn't.
- 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
- Open claude.ai
- Switch to the Code tab
- Type anything (e.g. "ey")
- 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 —
claudein 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)
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗