Sefirah: a Windows Phone Link alternative that pairs with Android over your own network

What Sefirah replaces, and for whom

Sefirah is a desktop application written in C# that connects a Windows PC to an Android phone over the local network. The README describes it as an alternative to existing solutions, and the feature list makes the target obvious: clipboard sharing, media control, file sharing, Android storage inside Windows Explorer, notification toasts, screen mirroring through scrcpy, SMS, and phone calls. That is the same ground Microsoft's Phone Link and KDE Connect occupy.

The intended user is someone on Windows 11 who wants those features without a Microsoft account and without the cloud round trip that Phone Link performs for some of its work. Sefirah is GPL-3.0, the desktop repository is at shrimqy/Sefirah, and the Android client lives in a separate repository, shrimqy/Sefirah-Android. The project ships Windows builds through the Microsoft Store and Android builds through Google Play and IzzyOnDroid. There is no documented server component: the two apps talk to each other on the same network, and the Windows side creates the link into Android storage.

One caveat belongs at the top. The README has a short section titled Linux Status: support for Linux is limited, and some features available on Windows may not be available there. The topics list says windows and winui, not linux. Treat this as a Windows project that happens to build elsewhere.

How the connection is established and authenticated

The mechanism is peer discovery on the LAN plus a key check. Both devices must be on the same network. The Windows app is launched first and waits; the Android app then initiates the connection, either through manual connect or auto connect. The README is explicit that manual connect is faster, while auto connect spends more time determining which IP address works. That difference is a design trade-off: auto connect probes addresses, which is friendlier but slower.

When the Android device initiates, Windows shows a pop-up to accept or decline, and the README instructs the user to ensure the keys match on both devices. That is the authentication step, and it is manual by design. After acceptance, both apps navigate to their home screens, and the desktop waits for notifications to populate on first load.

Discovery is not the same as reachability. The README notes that if the devices see each other but cannot connect, the firewall is the likely cause, and ports 5149 to 5169 must be open. That is a range, not a single port, which suggests the apps negotiate or fall back across it. The README does not document which port carries which function, so a firewall rule must cover the whole range.

Installing Sefirah and making the first connection

There is no command-line installer. The Windows build is distributed through the Microsoft Store, and the Android build through Google Play or IzzyOnDroid. The README gives store links rather than build instructions, so the first step is installing both clients from those sources.

On Android, the onboarding page asks for permissions. The README warns that after attempting to grant notification access or accessibility permission, you may need to allow restricted settings from App Info, because Android blocks side-loaded apps from requesting sensitive permissions. If you install from IzzyOnDroid rather than Google Play, expect to hit that step.

Once both apps are installed, keep them on the same network and launch the Windows app. Then initiate from Android. The README's sequence is: launch the app on Windows and wait for the devices to show up; initiate the connection on Android using manual connect or auto connect; accept the pop-up on Windows and confirm the keys match; then wait for notifications to load on the desktop home screen.

The README's troubleshooting note for this stage is a firewall check. Ports 5149 to 5169 must be open. If discovery works and the connection does not, that range is the first thing to inspect.

Clipboard sync from Windows to Android works once the feature is enabled in device settings. Image syncing is separate, and received images only land on the Android clipboard if the option 'Add received images to clipboard' is enabled. For the reverse direction on Android 10 and later, three settings have to line up: clipboard sync in device settings, auto-detect clipboard on the Settings page, and either Shizuku access or a live ADB connection from the desktop. The app prefers Shizuku and falls back to ADB. Accessibility is a third fallback, and the README says it may not work in every scenario. Manual sharing is available through the persistent device status notification, the Quick Settings tile, or the share sheet.

The Android 15 notification restriction and the ADB workaround

Notification sync has a hard platform limit. The README states that due to Android's restrictions, sensitive notifications are no longer visible from Android 15 onwards. Sensitive notifications include the ones most people actually want on a desktop: message previews and authentication codes.

The documented workaround is an appops grant over ADB:

adb shell appops set com.castle.sefirah RECEIVE_SENSITIVE_NOTIFICATIONS allow

The package name in that command, com.castle.sefirah, is the Android app's identifier, and it is the same one used in the Google Play link. On some devices, the README names OnePlus specifically, the command fails until system optimization is disabled or permission monitoring is turned off for apps in Developer options, under Apps. After changing that setting, the command is run again. If ADB is connected, the desktop app attempts to grant the permission automatically when the device comes online.

This is the clearest example of a trade-off in the project. Sefirah routes around an Android restriction rather than accepting it, and the cost is a developer-mode setting and a shell command that may need to be repeated per device. Anyone unwilling to enable ADB should assume notification previews will be incomplete on Android 15.

Android storage in Explorer, and the folder-deletion warning

Storage integration mounts Android storage into Windows Explorer. It requires Android 11 or higher, and storage access permission must be enabled in the Android app's settings. The desktop app then creates a link to the Android storage in File Explorer.

The README flags this feature as still a bit experimental and says it may not work on all Windows versions, especially older Windows 10 builds and unofficial debloated Windows 11 builds. That is a narrow support window, and it is the second place where the project's reach is smaller than the feature list suggests.

The warning that follows is the most important line in the README: do not set the remote storage location to a pre-existing folder, because it will delete the contents of that folder. This is not a caveat about permissions or performance. It is a data-loss boundary. If you try this feature, point it at a new, empty directory and keep nothing you need in it until you have confirmed the behaviour on your own machine.

SMS, calls and mirroring: what is complete and what is not

SMS requires granting all permissions from the permissions page on Android, then reconnecting. After that, messages appear in the Messages tab on the desktop, and texts can be viewed and sent as SMS. Dual-SIM devices can switch SIMs. Attachments are not implemented, and the README says so directly. That rules out MMS and any workflow where a message carries a photo or a document.

Bluetooth calling has a pairing prerequisite: remove the Bluetooth device if it has already been registered with another app, then pair it to the PC either through the in-app Bluetooth pairing or through Windows settings. The README does not explain what happens if a device is paired to both, so the removal step reads as a requirement rather than a suggestion.

Screen mirroring uses scrcpy, the established open source Android mirroring tool, rather than a custom implementation. The README section on it is truncated in the repository text, so the exact options Sefirah exposes around mirroring are not documented in what is available. Media control and volume control from Android to the PC are listed as features without further detail on the protocol or the supported players.

Sefirah against KDE Connect and Phone Link

The closest equivalent is KDE Connect, which also pairs devices on a local network and also ships an Android client. The difference in approach is the desktop stack. KDE Connect is built around KDE and its Android app integrates with the KDE ecosystem; Sefirah is a WinUI application whose topics include fluent and winui, and its feature set is shaped around Windows Explorer integration and Windows notifications rather than a Linux desktop shell. If your desktop is Windows 11 and you want the Android storage link inside Explorer, Sefirah targets that case directly. If your desktop is Linux, the README's own Linux Status section points you elsewhere.

Phone Link is the other comparison, and the README positions Sefirah as an alternative to it. The practical distinction visible in the documentation is scope: Phone Link is a Microsoft product tied to a Microsoft account and Windows, while Sefirah is GPL-3.0, published from a GitHub repository, distributed through the Microsoft Store and on Android through Google Play and IzzyOnDroid. The README does not make claims about what Phone Link does or does not do, so the comparison should be drawn from your own requirements rather than from the project's description.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-19, five days before this writing. Releases are frequent enough to be worth noting: v3.0.0 was tagged 'Magician' on 2026-07-17, v3.0.1 followed on 2026-07-23, and v3.1.0 on 2026-08-30. That cadence means the practical upgrade cost is keeping the Windows and Android clients on compatible versions, since the two live in separate repositories and the pairing and permission flow depends on both sides agreeing.

The licence is GPL-3.0. For an end user, that means the desktop application is free software with source available, and modifications you distribute carry the same licence. It does not restrict private use. If you are considering embedding Sefirah in a commercial product, the copyleft terms are the relevant part, and that is a question for a lawyer rather than for this article. Localisation runs through Crowdin, which the README links, so translations are community-maintained and may lag the English text.

The upgrade cost that is easy to underestimate is the permission state. Shizuku access, the ADB appops grant for sensitive notifications, and the storage access permission are all set outside the app, and a reinstall or a device change can reset them.

Editorial conclusion

Sefirah is for Windows 11 users who want clipboard, notification, file, SMS and screen-mirroring sync with an Android phone and are willing to open ports 5149 to 5169 and grant Shizuku or ADB access. It is not for Linux desktops, where the README states support is limited and features may be missing, and it is not for anyone who needs notification content on Android 15 without the ADB appops command. Before adopting it, verify three things: that the Android storage link does not point at a folder you care about, that the sensitive-notification appops command succeeds on your device, and that your firewall allows the port range.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. shrimqy/Sefirah on GitHub