Sefirah-Android pairs an Android phone with a Windows PC, with Shizuku doing the clipboard work

One Android app, one Windows app, one local network

Sefirah exists to link an Android phone to a Windows PC so the two behave like one device for the handful of tasks people actually want on a desktop. The project describes itself as an alternative to existing solutions of that kind, and the repository is the Android half of it. The Windows half is a separate project, Sefirah, published under the same author, and the documentation is explicit that feature requests and bug reports for the desktop app go to that other repository unless the problem is Android only.

That split matters when you adopt it. You are installing two applications, and the connection between them is a negotiated session between devices on the same network rather than a cloud relay, which means the pair has to see each other locally and the firewall has to allow the traffic.

The feature list covers clipboard sharing, ringing the phone from the desktop, media control of the PC from Android, file sharing, Android storage mounted into Windows Explorer, notifications toasted on the desktop, screen mirroring and control through scrcpy, SMS texting and phone call handling from the PC. It is an ambitious surface for a utility, and it is entirely oriented towards a Windows desk.

Support for Linux is explicitly limited, with the documentation warning that some features available on Windows may not be available on Linux. This is a Windows-first project.

Auto-detecting the Android clipboard needs Shizuku, ADB or accessibility

Clipboard sharing is the feature people come for, and it works in two directions with very different mechanics on each side.

From the desktop to Android it is simple. When you copy something on the PC it arrives on the phone, provided the feature is enabled in the device settings, and images are included if image syncing is on. One condition catches people out: the Add received images to clipboard option has to be enabled for received images to land on the Android clipboard.

From Android to the desktop it depends on the platform. Android 10 introduced clipboard restrictions that block background apps from reading the clipboard, so the app needs elevated access. The documentation lists a preference order. Enable Clipboard sync in the device settings, then enable Auto-detect clipboard on the app settings page, then grant Shizuku access if you use it or keep the device connected over ADB from the desktop app. The app prefers Shizuku when it is available and falls back to ADB.

Accessibility is the last resort. It works only if you have granted the accessibility permission, and the documentation warns that it may not work in every scenario.

There is also a manual path that does not depend on any of this: the persistent status notification, the Quick Settings tile, or the share sheet. If you need clipboard in both directions reliably, plan on Shizuku rather than on accessibility.

Notification sync breaks on Android 15 and needs an appops grant

Notifications are the most compromised feature in the list. From Android 15 onwards, sensitive notifications are no longer visible to Sefirah because of Android's own restrictions, and the documentation gives the way around it as a single ADB command.

adb shell appops set com.castle.sefirah RECEIVE_SENSITIVE_NOTIFICATIONS allow

That command grants the app operation permission to receive sensitive notifications. It needs ADB, which means either a developer machine or a machine with wireless debugging configured, so it is a step that only some users will take.

Two follow-on details are worth knowing. On some devices, such as OnePlus, the command may fail until system optimization or Disable permission monitoring is turned off for the app in Developer options, under Apps. After that the command has to be run again. And if ADB is already connected, the desktop app attempts to grant this permission automatically when the device comes online, which removes the manual step in the setup where wireless debugging is already in use.

So the notification feature has a graded experience: partial by default on Android 15 and later, complete once the appops permission is granted, and awkward on OEM builds that monitor permissions.

Android storage in File Explorer, and a folder deletion warning

The storage integration feature links Android storage into Windows Explorer, so files on the phone appear in the file manager on the PC. It needs Android 11 or higher, and storage access permission has to be enabled in the Android app settings before the desktop app creates the link.

The documentation attaches two warnings, and they are not decorative. The feature is described as still a bit experimental, and it may not work on all Windows versions, especially older versions of Windows 10 and unofficial debloated Windows 11 builds. The second warning is the serious one: do not set the remote storage location to a pre-existing folder, because doing so deletes the contents of that folder.

That is a footgun in the implementation rather than in the concept. A mounted remote share should never be able to clear a local directory, and here the documented behaviour is that it does. Anyone deploying this to non-technical users should treat the storage link as opt-in and never point it at a folder with data in it.

File transfer, by contrast, has no such hazard. You use the share sheet on either device and pick the app, which is the ordinary Android sharing flow.

SMS, calls and media control, with attachments still missing

The phone features run through the desktop app. For SMS you grant the permissions on the Android permissions page, reconnect, and the messages appear in the Messages tab, where you can view and send texts and switch SIMs on a dual SIM device. Attachments have not been implemented, which the documentation states plainly, and that is a real gap for anyone whose SMS workflow depends on sending pictures.

Bluetooth calling is handled by removing the Bluetooth device if it is already registered with another app, then pairing it to the PC through the in-app flow. That requirement to deregister from another application is the kind of friction that comes from Android's Bluetooth ownership model, and it means the feature cannot share a pairing with the rest of your phone setup.

Media control goes the other way: you control media playback and volume of your PC from the phone. Play Sound is the simplest of the set, ringing the phone from the desktop so you can find it, which is the feature most likely to survive being used on a Linux machine even if the documentation warns that some Windows features may not exist there.

Screen mirroring and control go through scrcpy, so the mirroring path depends on an external tool being present and configured rather than on anything Sefirah implements itself.

Getting the two devices to trust each other over ports 5149 to 5169

Setup is a sequence of small steps, and most of the friction is in permissions rather than in networking. On the phone you allow the permissions on the onboarding page, and the documentation calls out a specific Android behaviour: side-loaded apps are blocked from requesting sensitive permissions, so after attempting to grant notification access or accessibility permission you have to allow restricted settings from App Info.

Both devices then need to be on the same network. Launch the app on the Windows PC, wait for the devices to appear on both sides, and initiate the connection from the phone. Manual connect is faster, while auto connect takes longer because it has to work out which IP address works for you. Windows then shows a pop-up to accept or decline the connection, and you have to make sure the keys match on both devices before accepting.

After authentication, both apps land on their home screens, and the first load of notifications on Windows takes a moment.

If the devices discover each other but cannot connect, the documentation points at the firewall and at a port range that has to be open, 5149 to 5169. That range is wide, which is worth noting for anyone writing firewall rules for a managed network.

File transfer, storage linking and the rest are configured after the session is up, so the connection and permission steps are the ones to get right first.

A clean-architecture Kotlin repository with a GPL-3.0 licence and a separate desktop app

The Android repository is laid out like a modern Android application. The top level holds app, core, data, domain, features and worker modules alongside build-logic, a gradle.properties, settings.gradle.kts and a lint.xml, with the Gradle wrapper checked in. The module split is what the topics tag clean-architecture refers to, and it is a sensible structure for an app with a network session, a device protocol and several feature surfaces.

The build is Kotlin DSL based, with the wrapper and the gradle directory committed, and there is a fastlane directory that holds the store listing metadata, including the feature graphic used in the readme banner. The app is distributed through Google Play and through IzzyOnDroid, and the Windows app comes from the Microsoft Store. The application id visible in the permission workaround is com.castle.sefirah, which is the id to use in ADB commands.

The licence is GPL-3.0, which matters more here than for a typical Android dependency. Linking a phone to a PC and toasting notifications on the desktop is a distributed work in a broader sense, and a copyleft licence on the Android app has consequences for how modified versions are distributed. If you intend to fork it for your own organisation, read the LICENSE file and have whoever owns your compliance process look at it. This is a pointer, not legal advice.

The project moved quickly through the summer of 2026, with v3.0.1 on 2026-07-23, v3.1.0 on 2026-08-30 and v3.2.0 on 2026-10-14, and the last push was on 2026-10-15. The desktop app version has to match, and since it lives in a different repository, that coordination is on the user.

Editorial conclusion

Sefirah-Android suits a Windows user who wants clipboard, notification and file sharing with an Android phone and is willing to grant accessibility access or run Shizuku, since the auto-detect clipboard feature depends on one of those paths. It does not suit Linux users, who get limited support, or anyone whose notifications carry sensitive content on Android 15 without the appops workaround. Before adopting it, install the Android app from Google Play or IzzyOnDroid, install the matching Windows app from the Microsoft Store, put both devices on the same network with ports 5149 to 5169 open, and confirm the key match prompt on both screens before trusting the pair with anything private.

Frequently asked questions

Official sources

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