Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [BUG] SSH from Windows shows macOS keyboard glyphs in shortcut hints [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#54648•Fetched 2026-04-30 06:39:54
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
0
Author
NoisyinkNoisyink
Participants
github-actions[bot]github-actions[bot]NoisyinkNoisyink
Timeline (top)
labeled ×3commented ×1

Error Message

Error Messages/Logs

RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

What's Wrong?

Claude Code renders keyboard shortcut hints using macOS glyphs (⌘, ⇧, ↵, ⌥) when the server-side host is Linux/macOS, regardless of the client platform actually displaying the UI. When SSHing into a Linux host from a Windows client, this results in shortcut labels that don't correspond to keys on the user's keyboard. The underlying key bindings still function correctly — this is a display/labelling bug only.

What Should Happen?

Expected behaviour Shortcut hints should display platform-appropriate labels for the client OS — Ctrl+, Shift+, Enter, Alt+ for Windows clients. Actual behaviour Shortcut hints display macOS glyphs (⌘, ⇧, ↵). Example from a permission dialog:

"Always allow ⌘⇧↵" "Allow once ⌘↵"

Error Messages/Logs

Steps to Reproduce

Run Claude Code on a Linux host (Debian 12 in this case). Connect to it via SSH from a Windows client. In my case: the built-in SSH connector inside Claude Desktop on Windows 11. Trigger any action that surfaces a permission prompt (e.g. ask Claude to write a file outside the working directory). Observe the action buttons in the dialog.

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.123

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

<img width="1016" height="308" alt="Image" src="https://github.com/user-attachments/assets/b4cf91b3-f483-45ec-bd39-66f8a4084424" />

Server: Debian 12, Claude Code 2.1.123 Client: Claude Desktop on Windows 11 (built-in SSH connector) Shell: bash Terminal: xterm-256color (typical SSH session)

Additional context The glyph style appears chosen based on server-side OS detection, with no signal from the SSH client. Notably, in this setup the client is Claude Desktop itself, which already knows it's running on Windows — so there's a plausible path for Desktop to pass that hint through to the remote Code session. Possible fixes (in order of preference):

Auto-detect client platform when running over SSH — particularly when the client is Claude Desktop, which can pass its OS through. Expose a config setting (e.g. shortcutStyle: "windows" | "macos" | "auto" in ~/.claude/settings.json, or a CLAUDE_SHORTCUT_STYLE env var) so users can override platform detection.

extent analysis

TL;DR

The most likely fix is to auto-detect the client platform when running over SSH, particularly when the client is Claude Desktop, which can pass its OS through.

Guidance

  • Investigate how to pass the client OS information from Claude Desktop to the remote Claude Code session, potentially using environment variables or configuration settings.
  • Consider adding a configuration setting, such as shortcutStyle in ~/.claude/settings.json or a CLAUDE_SHORTCUT_STYLE env var, to allow users to override platform detection.
  • Review the current server-side OS detection logic to determine why it's not considering the client platform.
  • Explore the possibility of using the SSH client's capabilities to provide hints about the client platform.

Example

No code snippet is provided as the issue does not contain sufficient technical details to generate a specific example.

Notes

The issue seems to be related to the server-side OS detection logic not considering the client platform when running over SSH. The provided information suggests that Claude Desktop, as the client, can pass its OS information to the remote session, which could be used to improve the detection logic.

Recommendation

Apply a workaround by exposing a config setting, such as shortcutStyle, to allow users to override platform detection, as this seems to be a more feasible short-term solution until a more robust auto-detection mechanism can be implemented.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#installation#API versioning#request timeout

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING