Add support for RemoteCommand option in kitten ssh

[zzhaolei]

Problem

When using kitten ssh, users cannot specify RemoteCommand in ssh_config, since OpenSSH can only execute a single RemoteCommand.

Solution

This PR adds support for a dedicated remote_command option in kitten ssh as an alternative. When users specify this option, kitten will execute the provided command on the remote machine after establishing the SSH connection, with behavior similar to OpenSSH's RemoteCommand option.

Changes

1. Added remote_command configuration option

File: kittens/ssh/main.py

• New option that accepts a shell command to execute on the remote machine
• Supports complex commands and shell constructs
• Fully documented in the option's help text

2. Implemented command execution logic

File: kittens/ssh/main.go

• Added prepare_remote_cmd() function to handle remote command preparation
• Supports both shell script and Python script contexts with appropriate encoding (base64 for Python)
• Integrated remote command into bootstrap script setup with proper placeholders

3. Updated bootstrap scripts

Files: shell-integration/ssh/bootstrap.py and bootstrap.sh

• Added execution of remote command if specified
• Properly decodes and executes the command in the user's shell
• Maintains compatibility with existing shell integration

Usage Example

remote_command if command -v fish >/dev/null 2>&1; then exec fish; else exec $SHELL -l; fi

The above command will check if the fish shell is available on the remote machine. If it exists, it will be executed; otherwise, the default login shell will be used instead.

[kovidgoyal]

Why not just use the actual RemoteCommand in the ssh config, as
described here: #3988 (comment)

Remember to reset the RemoteCOmmand to empty on the actual command line
when executing ssh.

[zzhaolei]

Sorry, I didn’t see this issue earlier.

Right now my approach is to parse the SSH config (ssh -G) to extract the user-defined RemoteCommand, then execute it inside the kitten script, while explicitly overriding (RemoteCommand=none) on the actual ssh invocation to avoid double execution.

At the moment I’m only parsing remotecommand. Do you think it’s necessary to also parse and handle other fields from the SSH config in this context?

[kovidgoyal]

On Mon, Apr 13, 2026 at 08:19:40PM -0700, zhaolei wrote: zzhaolei left a comment (kovidgoyal/kitty#9859) Sorry, I didn’t come across that issue earlier. Right now my approach is to parse the SSH config (`ssh -G`) to extract the user-defined `RemoteCommand`, then execute it inside the kitten script, while explicitly overriding (`RemoteCommand=none`) on the actual ssh invocation to avoid double execution. At the moment I’m only parsing `remotecommand`. Do you think it’s necessary to also parse and handle other fields from the SSH config in this context?

What other fields? As far as I know most ssh config directives will work automatically when ssh is called via the kitten. Also, there is a performance concern. Does running ssh -G take a lot of time? I wouldnt want to slow down everyone's usage for a niche use case. If it does take a lot of time, then it might be better to have an option in the config that turns on checking RemoteCommand.

[zzhaolei]

Does running ssh -G take a lot of time?

This is the speed of executing ssh -G on my machine(Apple M4 Pro):

$ time /usr/bin/ssh -G bd-edit
...
________________________________________________________
Executed in   13.72 millis    fish           external
   usr time    4.73 millis    0.42 millis    4.30 millis
   sys time    6.16 millis    2.20 millis    3.96 millis

[kovidgoyal]

Hmm For me:

On Linux:
hyperfine -N 'ssh -G main'    master 
Benchmark 1: ssh -G main
Time (mean ± σ): 3.8 ms ± 0.3 ms [User: 2.4 ms, System: 1.3 ms]
Range (min … max): 3.2 ms … 5.2 ms 654 runs
On macOS:
hyperfine --warmup 10 -N 'ssh -G main'
Benchmark 1: ssh -G main
Time (mean ± σ): 3.9 ms ± 0.1 ms [User: 1.5 ms, System: 0.9 ms]
Range (min … max): 3.7 ms … 4.2 ms 713 runs

I guess it depends on how much you have in your ssh config files too.

4 ms is ok 13 ms is probably not. Possibly have it run at the beginning
of run_ssh() asynchronously and wait for the results only when actually
needed close to the bottom of run_ssh()

[kovidgoyal]

Apologies closed this accidentally.

[zzhaolei]

I refactored it into an asynchronous version. Based on simple testing, it reduced latency by about 5ms.

test like:

now := time.Now()
...
debugprintln(time.Since(now))