[BUG] showing Mac Key-symbols on windows
Status Fixed / completed
Maintainer reply None cached
Activity 5 comments · opened Apr 14, 2026 · closed Aug 25, 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?
I'm seeing mac key symbols on my windows machine in claude for windows for when I have to approve commands.
claude thinks "the key-symbol formatter isn't branching on process.platform"
<img width="1061" height="281" alt="Image" src="https://github.com/user-attachments/assets/20fbddec-97fc-400c-b759-d4b27f170c22" />
What Should Happen?
it should show ctrl+enter or ctrl+shift+enter
Error Messages/Logs
Steps to Reproduce
tell claude to do anything that requires approval in the windows app
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
Claude 1.2581.0 (f10398) 2026-04-14T17:16:40.000Z
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Other
Additional Information
_No response_
5 Comments
<img width="346" height="240" alt="Image" src="https://github.com/user-attachments/assets/01676773-462d-4093-b733-50172149a109" />
Same problem, Claude 1.5354.0 (9a9e3d) 2026-04-29T01:14:34.000Z. Screen cap from Claude Code GUI but exact same problem in Claude Chat and Claude Cowork GUIs.
Confirming this is still present in Claude desktop v1.7196.0.0 on Windows 11 Pro 26200 — the ⌘ glyph appears in permission prompts in place of "Ctrl" / "Ctrl+Shift" etc.
Worth flagging for triage:
regressionhere, and the parallel issue #48818 is closed as completed — so a fix shipped at some point and has since been undone. Whatever the fix was, it should still be in the git history; a revert-the-revert or a re-apply is probably the lowest-effort path back to a working state.stale) identifies the specific bundled JS files where the Mac glyphs are hardcoded without platform detection. That reporter did the legwork — worth not letting it auto-close for inactivity.Asking that this be removed from the auto-stale pipeline given the active duplicate cluster and the regression-from-prior-fix nature of the bug.
<img width="2442" height="583" alt="Image" src="https://github.com/user-attachments/assets/0fed8e02-464d-4a59-9ca3-9c25ecd65c77" />
Fix confirmed in Claude desktop v1.7196.3.0 on Windows 11 Pro 26200.
Permission prompts and keyboard hints now render the correct Windows modifiers (
Ctrl,Ctrl+Shift,Alt) instead of the macOS glyphs (⌘,⇧,⌥) across both the TUI and the desktop GUI. Last build where I could still reproduce the regression was 1.7196.0.0 (per my 5/15 comment above), so the fix shipped sometime between 1.7196.0.0 and 1.7196.3.0.Safe to close—thanks to whoever picked this up. Will reopen / re-file if it regresses again.
Problem persists for me in sidebar:
<img width="297" height="224" alt="Image" src="https://github.com/user-attachments/assets/24d6d598-ca61-47f9-922e-88af89d692c9" />
Still not a problem in hovertips:
<img width="285" height="148" alt="Image" src="https://github.com/user-attachments/assets/0d2773d6-d19e-49ca-bffd-caa167aee964" />
Never been a problem in menus:
<img width="405" height="201" alt="Image" src="https://github.com/user-attachments/assets/5b78842a-94a8-4e31-a811-eaaceb45589d" />
Claude 1.7196.3 (ca0c62) 2026-05-16T23:42:08.000Z
Windows 11 Enterprise version 25H2 build 26200.8390