Input Leap server fails to start on macOS Tahoe 26.5.2 (Apple Silicon) despite Accessibility permission

What happened?

Hello, I have been attempting to use Input Leap as the server on a Mac mini (Apple Silicon) running macOS Tahoe 26.5.2, with a Linux Mint 22.3 client. After several days of troubleshooting, I was unable to get the server to listen for incoming connections. Installing Deskflow on the same two machines worked immediately with the same network and permissions, suggesting the issue lies within Input Leap rather than the network or client. Environment • Hardware: Mac mini M1 (Apple Silicon) • macOS: Tahoe 26.5.2 • Input Leap versions tested: ◦ 3.0.3 (debug build) (soon realised this was the wrong version) ◦ 3.0.2 Apple Silicon release ◦ 3.0.1 Apple Silicon release • Client: ◦ Linux Mint 22.3 ◦ Connection over local LAN Symptoms (same for both 3.0.2 and 3.0.1) The Input Leap GUI starts normally. The status alternates between "Starting" and "Ready", but no server process ever begins listening on TCP port 24800. Running: lsof -iTCP -sTCP:LISTEN | grep 24800 never shows a listening socket. Consequently, clients cannot connect. Manual execution Running the server executable directly using the generated configuration consistently reports: FATAL: assistive devices does not trust this process, allow it in system settings. even after the application has been granted Accessibility permission in System Settings. Accessibility troubleshooting performed The following were attempted: • Removed and re-added Accessibility permissions. • Reset the TCC Accessibility database. • Rebooted macOS. • Re-authorised Input Leap. • Confirmed Local Network permission. • Confirmed the GUI launches normally. Despite this, the helper process still reports that it is not trusted. Additional observations The GUI launches a helper executable (input-leaps) which immediately exits. No listening socket is ever created. Inspection suggested that the GUI and helper have different executable identifiers, and both were unsigned (TeamIdentifier=not set). This may indicate a macOS permission or code-signing issue affecting the helper process rather than the GUI itself. Comparison Installing Deskflow on the same two machines, using the same network and permissions, resulted in a working configuration after starting the server from the Deskflow GUI. Once the server was running, the Linux client connected immediately and keyboard, mouse and clipboard sharing all functioned correctly. Suggestion It may be worth investigating whether recent versions of macOS Tahoe treat the helper process differently from earlier macOS releases, particularly regarding: • Accessibility authorisation of the helper executable, • code signing of the helper, • helper process launch, • server initialisation. I would be happy to provide additional logs or perform further testing if it would be useful. Kind regards, Graham Stoddart-Stones

Version

v3.0.0

Git commit hash (if applicable)

No response

If applicable, where did you install Input Leap from?

Downloaded from Github Releases

What OSes are you seeing the problem on? (Check all that apply)

macOS

If applicable, are you using Wayland or X11?

X11

What OS versions are you using?

macOS Tahoe 26.5.2 (as server) Linux Mint 22.3 Zena (as client)

Relevant log output

Any other information

No response