[BUG] Permission prompt buttons display mac keyboard glyphs on Windows

Resolved 💬 2 comments Opened Apr 26, 2026 by travw Closed May 30, 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?

Symptom

In the tool permission prompt (e.g., "Allow Claude to use PowerShell?"), the
keyboard shortcut hints on the buttons show macOS glyphs:

  • "Allow once" button: ⌘⇧⏎
  • "Always allow" button: ⌘⏎

<img width="1224" height="180" alt="Image" src="https://github.com/user-attachments/assets/67e500b1-c412-478b-9c04-fe6c1c33be7d" />

What Should Happen?

Expected on Windows: Ctrl+Shift+Enter and Ctrl+Enter (or equivalent
windows-appropriate text).

The actual key bindings work correctly -- pressing Ctrl+Enter triggers
"Always allow", Ctrl+Shift+Enter triggers "Allow once". Only the displayed
icons are wrong.

This has been shipping in the Windows desktop app for at least 4+ weeks across
~20 version updates.

Prior art

Two prior issues filed and closed-as-completed, but the bug still reproduces
on 1.4758.0.0
on Windows 11 (whatever fix was intended did not ship to the
current installable build, or it regressed):

  • #48818 (closed last week, conversation now locked)
  • #53077 (closed yesterday, includes screenshot)

Filing this fresh per the GitHub Actions bot's instruction on #48818 ("file a
new issue and reference this one if relevant"). Including more codebase-level
detail below than the prior reports had, since the fix clearly didn't take.

Environment

  • Claude desktop 1.4758.0.0 (MSIX package, installed via web installer from anthropic, NOT MS Store -- both ship the same package)
  • Windows 11 Pro build 22621
  • Reproducible on every Windows install I've checked

Root cause

Hardcoded mac glyph string literals with no platform check in two bundles:

Bundle 1: app/resources/ion-dist/assets/v1/c11959232-DvyLDI18.js

8 hardcoded literals: 6x "⌘⏎" and 2x "⌘⇧⏎". None of them have a platform
check. Example offending JSX:

r.jsxs("div",{className:"flex gap-[8px]",children:[
  r.jsxs(Sl,{
    size:"base",
    variant: n?"contained":"primary",
    onClick:()=>p("once",!1),
    children:[
      r.jsx(m,{defaultMessage:"Allow once",id:"O2tb5KUxpc"}),
      r.jsx(Bx,{children: n ? "⌘⇧⏎" : "⌘⏎"})  // <-- always mac glyphs, never platform-aware
    ]
  }),
  n ? r.jsxs(Sl,{
    size:"base",
    variant:"primary",
    onClick:()=>p("always",!1),
    children:[
      r.jsx(m,{defaultMessage:"Always allow",id:"lr3QX/nctD"}),
      r.jsx(Bx,{children: "⌘⏎"})  // <-- always mac glyphs
    ]
  }) : null
]})

Other instances in the same bundle use the same "⌘⏎" / "⌘⇧⏎" pattern
(see contexts at offsets 195343, 282189, 300075, 300447, 300596, 392206,
392378 in the minified file).

Bundle 2: app/resources/ion-dist/assets/v1/index-nw6xXXcG.js

Uses an h ? ternary on what looks like a platform flag, but h appears to be
evaluating truthy on Windows in some code paths:

m.jsx("kbd",{
  className:"ml-1.5 font-small text-text-500",
  children: h
    ? m.jsx(L,{defaultMessage:"⌘⏎", id:"OIYTyBtj+D"})
    : m.jsx(L,{defaultMessage:"Ctrl⏎", id:"AtKbetYQq6"})
})

There's also a correct platform-aware lookup table function ND in the same
file:

function SD(){return oI(()=>MD.test(window.navigator.userAgent),!1)}
function ND(e,t){
  // ...
  // if (t) -> mac glyphs lookup: { ctrl:"⌃", shift:"⇧", cmd:"⌘", ... }
  // else -> ascii lookup: { ctrl:"Ctrl", shift:"⇧", cmd:"Ctrl", ... }
}

So the platform-aware machinery exists -- the permission prompt component just
isn't using it.

Note: main process is fine

The main process bundle at .vite/build/index.js has a correct platform-aware
lookup table:

const lLn = { /* mac chars */ };
const uLn = { /* windows chars */ };
const Ket = zr ? lLn : uLn;          // zr = process.platform === "darwin"
const ILn = zr ? "" : "+";

So menu shortcuts and keyboard accelerators rendered by the main process work
correctly on Windows. Only the renderer-side permission prompt is broken.

i18n strings

ion-dist/i18n/en-US.json has both messages defined:

  • OIYTyBtj+D: "⌘⏎"
  • AtKbetYQq6: "Ctrl⏎"

A platform-aware component would pick AtKbetYQq6 on non-mac. Several call
sites pick OIYTyBtj+D unconditionally or behind a wrong-evaluating flag.

Suggested fix

Replace the hardcoded mac glyphs in c11959232-*.js permission button JSX with
the same platform-aware helper that already exists in the codebase
(ND/SD from index-*.js, or wire through the i18n OIYTyBtj+D /
AtKbetYQq6 pair with a proper platform check).

Minimal patch sketch:

// before
r.jsx(Bx,{children: n ? "⌘⇧⏎" : "⌘⏎"})

// after
const isMac = process.platform === 'darwin';  // or window.navigator.userAgent regex
r.jsx(Bx,{children:
  n ? (isMac ? "⌘⇧⏎" : "Ctrl+Shift+Enter")
    : (isMac ? "⌘⏎"  : "Ctrl+Enter")
})

Impact

Cosmetic only. The actual Ctrl+Enter / Ctrl+Shift+Enter keybindings work on
Windows. But every Windows user of claude desktop has been seeing wrong
keyboard hints on every permission prompt for at least a month.

Error Messages/Logs

Steps to Reproduce

Reproduction

  1. Install claude desktop 1.4758.0.0 on Windows 11
  2. Start any session that triggers a tool permission prompt (e.g., ask claude

to run a powershell command)

  1. Observe the "Allow once" and "Always allow" button hints display ⌘⇧⏎ and

⌘⏎ respectively

100% reproducible.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.119

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_

View original on GitHub ↗

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