anthropics / anthropics/claude-code
[BUG] Desktop (Windows): Browser pane paints a duplicate mirrored "ghost" copy over the chat in Hebrew (RTL) sessions
- Dominant language
- Python
- Stars
- 145k
- Forks
- 23.1k
- PR merge metrics
- PR metrics pending
Description
## Environment
- **App**: Claude Desktop (Code tab), app-2.110.0
- **OS**: Windows 11 Pro 10.0.26200
- **Windows UI language**: en-US (LTR); system locale he-IL
- **Session language**: Hebrew (RTL) — session title, chat content, and page content are all Hebrew
## Bug description
When working in a Hebrew (RTL) session with the built-in Browser pane open, a **duplicate "ghost" copy of the Browser pane is rendered over the chat area**, hiding the conversation. The real Browser pane renders correctly in its slot on the right; the ghost copy appears over the chat transcript and shows identical content.
Two observations that point at an RTL coordinate bug:
1. **The ghost sits at the horizontally mirrored position of the real pane.** In a ~1920px-wide window, the real pane spans roughly x = 985–1900 and the ghost spans roughly x = 185–930 — almost exactly the RTL mirror (1920 − 1900 = 20, 1920 − 985 = 935) of the real pane's bounds. It looks like one code path positions the native browser layer using RTL-flipped coordinates and another uses LTR coordinates, and one of the two paints is never cleaned up.
2. **The ghost survives the pane being closed.** While the ghost was visible on screen, `tabs_context` (called by Claude from inside the session) reported `browserOpen: false` with no tabs — i.e., the app believed the Browser pane was fully closed while its ghost layer was still painted over the chat.
## Steps to reproduce
1. Windows 11, Claude Desktop, Code tab.
2. Start a session conducted in Hebrew (RTL content; RTL rendering active in the Code tab).
3. Have Claude open the built-in Browser pane (`preview_start` / `navigate`) and browse a page.
4. A duplicate copy of the Browser pane content appears over the chat area, mirrored horizontally relative to the real pane.
## What I tried (didn't help)
- Closing and reopening the Browser pane (including closing the last tab so the pane fully closes) — ghost persists.
- Minimizing/restoring and resizing the app window.
- The issue is long-standing across app versions, not a one-off glitch.
## Expected
The Browser pane should render exactly once, in its designated pane slot, regardless of the session's text direction; closing the pane should remove its native layer from the window.
## Possibly related (RTL-on-Windows family)
- #53255, #61119 — window control buttons misplaced/overlapping with Hebrew RTL display language
- #49521, #38005 — RTL text alignment/support in Claude Desktop
Contributor guide
No contributing guide indexed for this repository
Research direction
Reproduce the issue on Windows 11 with Hebrew RTL content and the Browser pane open. Trace the pane lifecycle around preview_start, navigate, and tabs_context while comparing the real and mirrored bounds. Done means the Browser pane paints once in its assigned slot and closing it removes the native layer.
Written by the indexing model from the issue text.
Assessment
- Domain
- desktop, localization
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100