TrixConnect
Remote desktop and remote support software: a native Windows service, a macOS agent, signed installers for both, and a browser-based viewer connected over WebRTC. The deepest systems work in the portfolio.
Remote support tools stop working exactly when you need them.
The moment a remote machine reaches its lock screen, most remote-support tools go blank — which is precisely the moment somebody needs help getting back into it. Reboot, and the session is gone entirely.
TrixConnect is built around that requirement rather than around it. Working at the lock screen dictated the process model, the installer and the privilege design.
Every surface, by us.
Capturing a screen you are not allowed to see.
Windows deliberately isolates the lock screen from ordinary applications. Getting a picture of it legitimately is most of the engineering.
The lock screen lives on a different desktop
The secure desktop is a separate object that a normal user process cannot attach to. The capture path runs with a system token attached to that desktop and duplicates the display output from there — which is what makes the lock screen, and the login prompt, visible to a remote technician.
It was proven before it was built on
Before any session or state-machine work went on top, a dedicated harness answered one question on the actual dual-GPU target hardware: does this capture path survive a lock transition. Everything else was written only after that came back yes.
Session isolation makes logs the only truth
A process on the secure desktop has nowhere to print — console output is simply invisible there. Diagnostics go to a file and to the system debug channel, because on that desktop a log is the only observation available.
macOS permissions attach to the host process, not the user
Screen recording and input permissions on macOS are granted to whichever process hosts the code. A verification run over SSH fails no matter what has been granted, because the SSH session is a different process — so the verification suite is specified to run from the terminal application itself.
The client mints its own credential
A host generates 32 random bytes as its machine token and presents it at enrolment; the server validates it and never issues one. The identity pair in the request body is the credential, and a request without a well-formed token is rejected outright.
What it runs on.
We build these for ourselves. We build them for clients too.
Everything on this page was designed, built, deployed and is operated by the same small senior team. If you have a product that needs the same treatment, start with a conversation.