Software Version: 2026.12
Computer System: Arch Linux, XFCE4/X11 (native build, not Flatpak/AppImage)
Description:
In the Clone dialog, clicking the file-picker button next to the SSH key field opens a file chooser that only shows files with a dot in the name. OpenSSH private keys generated by ssh-keygen have no extension by default (e.g. id_ed25519, or any custom name like gitea_personal_ed25519) — only the matching .pub public key file has one. As a result, the actual private key file never appears in the picker; only its .pub counterpart does.
Root cause
src/Views/Clone.axaml.cs, SelectSSHKey:
private async void SelectSSHKey(object _, RoutedEventArgs e)
{
var options = new FilePickerOpenOptions()
{
AllowMultiple = false,
FileTypeFilter = [new FilePickerFileType("SSHKey") { Patterns = ["*.*"] }]
};
// ...
}
Patterns = ["*.*"] is presumably intended to mean "any file," matching the common Windows convention where *.* is colloquially read that way. But Avalonia's native file picker on Linux is backed by GTK, and GTK's glob filter treats *.* literally — it requires a dot in the filename to match. Extensionless files (i.e. essentially all default-named OpenSSH private keys) are filtered out, while .pub files pass because they have a dot.
Workaround found
Selecting the .pub file instead of the private key works fine — ssh(1) (per ssh_config(5)'s IdentityFile documentation) resolves the corresponding private key from the agent when given a public key path and the private key isn't present locally. So the clone itself isn't blocked, but it's not obvious from the UI that you're supposed to pick the .pub file, and a user who does want to point at a private key file directly (e.g. not using an agent) cannot select it through this dialog at all on Linux.
Suggested fix
FileTypeFilter = [new FilePickerFileType("SSHKey") { Patterns = ["*"] }]
Patterns = ["*"] (no dot) matches everything regardless of platform-specific glob interpretation, and avoids the Linux-specific gap without affecting Windows/macOS behavior.
I'm filing this as an issue rather than going straight to a PR in case there's a reason for the current pattern I'm not seeing (e.g. some other platform's picker needing the *.* form) — happy to open a PR with the one-line fix above if that's preferred.
Written by Claude Code, supervised by me.
Software Version: 2026.12
Computer System: Arch Linux, XFCE4/X11 (native build, not Flatpak/AppImage)
Description:
In the Clone dialog, clicking the file-picker button next to the SSH key field opens a file chooser that only shows files with a dot in the name. OpenSSH private keys generated by
ssh-keygenhave no extension by default (e.g.id_ed25519, or any custom name likegitea_personal_ed25519) — only the matching.pubpublic key file has one. As a result, the actual private key file never appears in the picker; only its.pubcounterpart does.Root cause
src/Views/Clone.axaml.cs,SelectSSHKey:Patterns = ["*.*"]is presumably intended to mean "any file," matching the common Windows convention where*.*is colloquially read that way. But Avalonia's native file picker on Linux is backed by GTK, and GTK's glob filter treats*.*literally — it requires a dot in the filename to match. Extensionless files (i.e. essentially all default-named OpenSSH private keys) are filtered out, while.pubfiles pass because they have a dot.Workaround found
Selecting the
.pubfile instead of the private key works fine —ssh(1)(perssh_config(5)'sIdentityFiledocumentation) resolves the corresponding private key from the agent when given a public key path and the private key isn't present locally. So the clone itself isn't blocked, but it's not obvious from the UI that you're supposed to pick the.pubfile, and a user who does want to point at a private key file directly (e.g. not using an agent) cannot select it through this dialog at all on Linux.Suggested fix
Patterns = ["*"](no dot) matches everything regardless of platform-specific glob interpretation, and avoids the Linux-specific gap without affecting Windows/macOS behavior.I'm filing this as an issue rather than going straight to a PR in case there's a reason for the current pattern I'm not seeing (e.g. some other platform's picker needing the
*.*form) — happy to open a PR with the one-line fix above if that's preferred.Written by Claude Code, supervised by me.