dwservice agent: the open source remote access client behind DWService

The client half of a hosted remote access service

The dwservice repository holds the agent for DWService, which the README describes as an agent for operating systems Linux, Mac and Windows, and the project description calls it the DWService agent for Linux, Mac and Windows. The important word there is agent. This is not a standalone remote administration product with its own server, it is the piece that runs on the machine you want to reach and connects out to the DWService service. The code is written in python2 with several libraries written in C++, which is an unusual combination today and tells you something about the age of the code base. The repository topics list remote access, remote admin tool and remote control, and the project is hosted under a dwservice organisation with a download page as its homepage. The audience is a developer who needs to build or modify the agent, or a user who wants to understand what the agent does on their machine before letting it run.

Building from source means you also own the updates

The start-up section opens with a warning that is really the whole story of this repository: if you start the agent from the sources, the agent does not update automatically, so you need to update the sources manually every time. That single sentence separates this build path from the packaged binary, and it changes the maintenance math entirely. The prerequisites are Python 3, a compiler and make, and on Windows the README points you at the Mingw-w64 toolchain with links to 64 bit and 32 bit builds. On Linux, compiling the Wayland support needs libpipewire-0.3-dev, libdbus-1-3 and libdbus-1-dev. You then download the source, either as a zip archive or with git clone, and run two scripts from the agent/make directory.

python3 ./compile_all.py; # Compile all c++ libraries.
python3 ./create_config.py; # Create Agent config.json in agent/core path.

The first script builds the C++ libraries and the second generates the agent config file in the agent/core path, so the order matters. With those done you start the agent from agent/core.

python3 ./agent.py;

Wayland on Linux is the part that fights back

The README describes a specific failure on modern Linux desktops. If the agent still tries to set up an Xorg session on client connect, even with Wayland active and even with the XDG_SESSION_TYPE environment variable set to wayland, the fix is to force Wayland in the agent configuration, which means adding a desktop block with a force_capturescreenlib entry set to wayland. That is a small configuration change, and the reason it exists is that the screen capture path on Linux has two entirely different implementations, one for X11 and one for Wayland, and the agent has to be told which one to use rather than inferring it. The Wayland libraries required at build time, PipeWire and D-Bus, are the same two technologies that the Wayland capture path depends on, which is why they appear in the prerequisites list rather than as optional extras. For a user on a modern GNOME or KDE session, this is the difference between a working session and a black screen, so it is worth checking before you assume the build is broken.

A hybrid tree of platform code, libraries and apps

The top level entries describe how the agent is put together, and the naming makes the layering obvious. There are core/ and lib_core/ for the agent itself, and a set of lib_ directories for the C++ pieces it depends on: lib_screencapture, lib_soundcapture, lib_rtaudio, lib_turbojpeg, lib_unwind, lib_z, lib_gdi, lib_gcc and lib_stdcpp, which is a rough map of the platform facilities the agent needs, from screen grabbing to audio capture to image compression and stack unwinding. Then there are app_ directories for the individual applications the agent can run, with app_desktop, app_filesystem, app_logwatch, app_resource, app_shell and app_texteditor. The os_ directories carry the platform variants, os_linux, os_mac, os_win_installer, os_win_launcher, os_win_service and os_win_updater, plus an os_mac_installer. The ui/ directory holds the interface code and make/ holds the build scripts. The .gitignore, README.md and make/ directory sit at the root.

Licensing is per component, and that is the first thing to read

The license section is the one part of the README that should be read before anything else, and it is not a single licence. The text says the software is free and open source, that it consists of one core component released under the MPLv2 license, and several libraries and components defined as app that could be governed by different licenses, and that you can read the LICENSE file in each folder. That is the practical difference between this project and a package with one licence file. If you are considering vendoring the agent or shipping it inside a product, the per-directory licences are what determine your obligations, and the app components are explicitly not guaranteed to be under the same terms as the core. The repository itself does not publish GitHub releases, the last push was on 2026-09-18, and the topic list still includes python27, which tells you the interpreter generation the code was written for even though the build scripts now run under python3.

Developing the agent in one IDE across the two languages

The development setup section takes an unusual but practical shape. It points at Eclipse with Pydev and the CDT C++ IDE, and the claim is that with those you can develop the agent with a single IDE from your preferred operating system, rather than a Python IDE on one machine and a C++ IDE on another. You still need python3 and a C++ compiler with make, and on Windows that means the same Mingw-w64 toolchain. After configuring the IDE and importing the source, you run the same two scripts from the start-up section, which is a nice consistency, because the build path for a developer and the build path for a user are the same two commands. A wiki guide covers the setup in more detail. The practical picture is a code base where a meaningful part of the work is in the C++ libraries and the rest is in Python, so an IDE that handles both saves a lot of context switching, and the cost is that the tooling is a specific stack rather than whatever you already use.

Where the agent is the wrong choice

There are two clear cases. The first is a team that wants a self-hosted remote support or administration tool. Nothing in this repository is a server, a scheduling layer or an account system, it is the client that connects to a hosted service, so building it does not give you a private remote access product, it gives you a different client for someone else's. The second is a user on a current Linux desktop, where the Wayland capture path is the fragile part and the README only tells you how to force it, not what happens when PipeWire is not present. There is also the maintenance question that the README puts plainly. A source build does not update itself, and for a component that runs with the privilege needed to capture the screen and inject input, a stale build is a real problem, which is why the packaged binary exists and is the sensible default. The alternative worth naming is a self-hosted remote access tool with its own server, where you own the update cycle and the trust boundary sits inside your network, and the cost of that choice is running the server infrastructure yourself.

Editorial conclusion

Adopt the dwservice agent source only if you need to build it yourself, for example to work on the screen capture libraries, because the packaged builds update automatically and the source build does not. Do not treat it as a general remote administration tool you can deploy unattended, since the project describes it as the agent for the DWService service rather than a standalone product. Verify first that you can install the compiler toolchain and the required libraries, and read the licensing section first, because the core and the app components are covered by different licences.

Frequently asked questions

Official sources

1. dwservice/agent on GitHub
2. Issues
3. Project website
4. README