# GSConnect: KDE Connect for GNOME Shell, Without the KDE App > GSConnect implements the KDE Connect protocol as a GNOME Shell extension, with Nautilus, Chrome and Firefox integrations. It is community maintained, GPL-2.0, and installs from extensions.gnome.org or a nightly build. **GSConnect/gnome-shell-extension-gsconnect** — KDE Connect implementation for GNOME - Repository: https://github.com/GSConnect/gnome-shell-extension-gsconnect - Stars: 3,723 · Forks: 321 - Language: JavaScript - License: GPL-2.0 - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/gsconnect-gnome-shell-extension-gsconnect ## What GSConnect solves for GNOME users KDE Connect is a protocol and a set of applications for linking a phone to a desktop: share files and links, send and receive messages, sync the clipboard, sync contacts and notifications, control media players, control system volume, and run predefined commands. The reference client is a KDE application. GSConnect is the same protocol implemented as a GNOME Shell extension, so a GNOME user does not have to pull in the KDE application stack to get those features. The README describes it as a complete implementation of KDE Connect especially for GNOME Shell, with Nautilus, Chrome and Firefox integration. The KDE Connect team, meanwhile, publishes applications for Linux, BSD, Android, Sailfish, iOS, macOS and Windows, so the phone side of a GSConnect pair is normally one of those apps rather than something GSConnect ships. The target user is someone on GNOME Shell who already has a phone running a KDE Connect client and wants clipboard, notification and file transfer wired into the desktop shell and the file manager. ## How the extension, Nautilus and browser pieces fit together The repository layout shows four cooperating parts rather than a single program. src/ holds the extension itself, written in JavaScript for GJS, the GNOME Shell JavaScript runtime, which is why the primary language is listed as JavaScript. nautilus-extension/ is a separate Python component, and pyproject.toml configures Black for that directory only, with line-length 80 and target versions py38 through py312, which tells you the Nautilus side is Python while the shell side is not. webextension/ holds the Chrome and Firefox add-ons that the README links to on the Chrome Web Store and Mozilla Add-ons. po/ holds translations and crowdin.yml points at Crowdin for translation work. The pairing and transport work is the KDE Connect protocol itself, which GSConnect implements rather than redefines; the README does not document the wire protocol or the discovery mechanism, so anything beyond that is inference from the upstream KDE Connect project. Practically, the shell extension manages devices and the UI, the Nautilus extension adds file-manager actions, and the browser add-ons send pages or links to the phone. ## Installing GSConnect from extensions.gnome.org The README's first link is the GNOME Extensions badge, which points at extensions.gnome.org/extension/1319/gsconnect/. That is the primary install path the project advertises. You enable the extension from that page or from the Extensions application, and the shell then exposes a GSConnect menu. Confirm the extension's supported GNOME Shell versions on that page before enabling it, because a shell extension built for an older shell release will not load. The README does not document a command-line install, a distribution package name, or a rollback procedure, so treat the extensions site as the canonical source and your distribution's packaging as a separate question. If you are on a distribution that ships GSConnect, the package name and version are set by that distribution, not by this repository, and the README does not list any of them. ## Installing a nightly build and pairing a first device For people tracking GNOME Shell releases ahead of the stable extension, the README points at an automated nightly build and a wiki page titled Installing from Nightly Build. The nightly archive is served from nightly.link and is named gsconnect@andyholmes.github.io.zip, which is also the extension's UUID. The README does not give the unzip or install command, only the download and the wiki pointer, so the exact placement of the extracted directory is something to read on that wiki page rather than guess. ```bash # Download the nightly archive named in the README # gsconnect@andyholmes.github.io.zip # Installation steps: see the wiki page "Installing from Nightly Build" ``` Once the extension is enabled, pairing follows the KDE Connect model: both ends must run a KDE Connect implementation and be on the same network. The README does not walk through the pairing dialog, so the specifics of the request/accept step belong to the KDE Connect documentation and the GSConnect wiki. After pairing, the features the README lists (files, links, text, messages, clipboard, contacts, notifications, media players, volume, predefined commands) appear in the shell menu and, for file operations, in Nautilus. If the device never appears, that is a discovery or firewall problem on the network, not something the README addresses. ## Where GSConnect is the wrong choice The README is unusually direct about maintenance: the project has migrated from a developer-driven model to a community-driven one, and it does not have dedicated developers working on new features or bug fixes. It relies on contributions from users and from distributions that choose to package it. That is a real constraint, not a disclaimer. If you need a vendor or a funded team behind a sync tool, or you need a support contract, GSConnect is the wrong pick. It is also the wrong pick if you are not on GNOME Shell: the whole point is shell integration, and KDE Connect's own applications cover Linux, BSD, Android, Sailfish, iOS, macOS and Windows, so a KDE, XFCE or macOS user has no reason to route through a GNOME extension. A third case is a locked-down machine where installing shell extensions is disallowed; the extension model itself is the blocker, independent of GSConnect's quality. Finally, the README's bug-report path assumes you can triage issues and review pull requests if you want the project to move faster, which is a fair description of what adopting a community-driven extension means over time. ## GSConnect versus the KDE Connect desktop application The honest alternative is KDE Connect itself. The difference is packaging and integration, not protocol: GSConnect is described as a complete implementation of KDE Connect for GNOME Shell, and the KDE Connect team publishes applications for Linux, BSD, Android, Sailfish, iOS, macOS and Windows. Running the KDE Connect desktop application on GNOME gets you the same protocol and the same phone-side compatibility, at the cost of pulling in KDE libraries and losing the shell-menu and Nautilus integration that GSConnect provides. GSConnect gets you tighter GNOME integration, at the cost of depending on a shell extension whose supported GNOME versions have to track shell releases; the v71 release notes title explicitly names GNOME 46-49, which shows how version ranges are declared per release. If you already run KDE applications, there is little reason to switch. If your desktop is GNOME and you want file-manager and browser actions, GSConnect is the more direct route. The browser add-ons are a GSConnect-specific extra: the README links a Chrome Web Store listing and a Firefox add-on, and KDE Connect's desktop application does not provide those. ## Licence, packaging and what upgrades cost you GSConnect is GPL-2.0, and the source files carry SPDX headers with GPL-2.0-or-later, so the project's own files are offered under the or-later form of that licence. The REUSE.toml and LICENSES/ directory in the repository root indicate the project applies the REUSE specification for licence and copyright metadata. For anyone embedding or redistributing GSConnect, the practical consequence is the usual copyleft one: derivative distributions carry the same licence obligations. That is a statement about the licence text, not legal advice; read the GPL-2.0 text in LICENSES/ and the SPDX headers if redistribution is on the table. On upgrade cost, the release history shows the cadence: v71 was titled for GNOME 46-49, v72 followed, and v73 is the current release. Each release is tied to a range of GNOME Shell versions, so an upgrade is usually a shell-version question first and a feature question second. The README also notes that distributions package GSConnect themselves, which means your upgrade path may be your distribution's, not the extensions site's, and the two can diverge. The README does not document a rollback procedure for a bad extension update. ## Conclusion Adopt GSConnect if you run GNOME Shell and want KDE Connect features without installing the KDE desktop stack: the extension and its Nautilus, Chrome and Firefox add-ons cover files, clipboard, notifications, messages, contacts and media control. Do not adopt it if you expect vendor-backed support; the README states the project moved to a community-driven model with no dedicated developers on features or bug fixes. Before installing, verify that the extension's GNOME Shell version range matches your release, check whether your distribution packages it, and confirm the phone-side app is installed, since pairing needs both ends of the KDE Connect protocol. ## FAQ ### Does GNOME have something like KDE Connect? Yes. GSConnect is described in its README as a complete implementation of KDE Connect especially for GNOME Shell, with Nautilus, Chrome and Firefox integration. It is distributed through extensions.gnome.org as extension 1319. ### What are the differences between KDE Connect and GSConnect? They implement the same protocol; the difference is packaging and integration. GSConnect is a GNOME Shell extension with Nautilus and browser add-ons, while the KDE Connect team publishes standalone applications for Linux, BSD, Android, Sailfish, iOS, macOS and Windows. ### Is the GNOME Shell extension safe? A shell extension runs inside GNOME Shell, so it has the shell's privileges, and the README does not make any security claims beyond the KDE Connect protocol it implements. GSConnect's source is published under GPL-2.0 with SPDX headers, so the code can be reviewed, and the project asks users to triage issues and review contributions. ### What is a GNOME Shell extension? It is a component that loads into GNOME Shell and adds behaviour to the desktop shell. GSConnect is one: it installs from extensions.gnome.org, adds a shell menu for paired devices, and its release titles track specific GNOME Shell version ranges such as GNOME 46-49. ## Sources - [GSConnect/gnome-shell-extension-gsconnect on GitHub](https://github.com/GSConnect/gnome-shell-extension-gsconnect) - [Issues](https://github.com/GSConnect/gnome-shell-extension-gsconnect/issues) - [License: GPL-2.0](https://github.com/GSConnect/gnome-shell-extension-gsconnect/blob/main/LICENSE) - [README](https://github.com/GSConnect/gnome-shell-extension-gsconnect/blob/main/README.md) - [Releases](https://github.com/GSConnect/gnome-shell-extension-gsconnect/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gsconnect-gnome-shell-extension-gsconnect