BUG: Ghostty send Ctrl+A Ctrl+E when Cmd+Left and Cmd-Right

[alex-jitbit]

Issue Description

CMD+arrow keys are hardcoded to send CTRL+A CTRL+E over ssh.

Instead of going start/end of the line I get whatever the remote running app's reaction to Ctrl+A is. For example in micro editor this brings up the "command bar"

This is opinionated and unexpected. And becomes a bigger issue with an external non-mac keyboard, where I can't use FN+arrow (I have no fn key at all).

Many, many people use their Macs in clamshell (closed) mode with external monitors and mechanical kayboards and we just can't use Ghostty normally over SSH

Reproduction Steps

1. Open Ghostty (Mac)
2. Connect to remote server over SSH
3. Run cat
4. Press Cmd-Left (to simulate "Home") Cmd+Right (to simulate "End")
5. You see ^A

Ghostty Version

Ghostty 1.1.3

Version
  - version: 1.1.3
  - channel: stable
Build Config
  - Zig version: 0.13.0
  - build mode : builtin.OptimizeMode.ReleaseFast
  - app runtime: apprt.Runtime.none
  - font engine: font.main.Backend.coretext
  - renderer   : renderer.Metal
  - libxev     : main.Backend.kqueue

OS Version Information

Macosx Sequoia 15.3.2

(Linux only) Display Server

None

(Linux only) Desktop Environment/Window Manager

No response

Ghostty Configuration

no config overrides

Additional Relevant Configuration

No response

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.

[00-kat]

over ssh

Make sure you have your terminfo, of course.

Could you look for super+a or cmd+a in ghostty +list-keybinds?

I'm also going to link this: #6929 (comment); I sent a snippet to correct it there too.

[alex-jitbit]

@00-kat I do

~ $ cat .ssh/config
Host *
  SetEnv TERM=xterm-256color

And in ghostty +list-keybinds I have

super + a                       select_all
...
super + right                   text:\x05
super + left                    text:\x01

But I haven't configured those, guess it comes as the default (which is what my issue is about)

[00-kat]

Huh. I had thought initially that only opt+left and opt+right were bound by default, but #3107 (the PR which changed it) says otherwise.

The solution would be to unbind them then, I guess:

keybind = cmd+left=unbind
keybind = cmd+right=unbind

---

The rationale for these default keybindings can be found at #2363 (comment) and some opposition is at #2363 (comment).

This is opinionated and unexpected.

In short, were you to not want to click the links above, Terminal.app does this so many macOS users came to expect it. The number of people who complained that the aforementioned keys were “broken” far outnumbered those who complain about these new keybindings (as silly as these keybindings may seem).

[alex-jitbit]

Ok. I think I understand whats' happening. MacOS uses ctrl+a and ctrl+e for "Home/End". Not just in terminal - everywhere, like in TextEdit for example. This is a weird combo so lots of apps modify cmd+left to translate to ctrl+a. Because MacOS.

So that when people type Cmd+left in termianl - it goes to the beginning of line.

However SSH does NOT use MacOS shortcuts. In SSH Ctrl+A is just that. An effing Ctrl+A. Which is ^A

Ok, I admit there's no solution for that. MacOS sucks.

Thanks for looking into this

[00-kat]

However SSH does NOT use MacOS shortcuts.

This is true…

In SSH Ctrl+A is just that. An effing Ctrl+A. Which is ^A

…but this isn't entirely true. A ctrl+a is a ctrl+a both in SSH and in a local shell; it's the shell which translates it to home/end. If ctrl+a doesn't take you to the start of a line over SSH, that means whatever shell you're running when SSH'd doesn't bind ctrl+a. See if there's something more featureful (such as bash or zsh) installed on the remote; and if you're already running bash or something maybe someone else configured that Bash to use Vi keys, which doesn't include ctrl+a.