Remote execution, file transfer, and synchronization between Linux and Windows.
CrossPilot is a lightweight remote agent designed to control Windows and Linux machines from another system, through a dedicated binary protocol.
It lets you execute commands, transfer files, synchronize directories, and manage remote filesystems without requiring Remote Desktop, SSH, or SMB shares.
One agent. Any host. Full control.
CrossPilot provides a single remote channel for system operations:
- 🖥️ Remote command execution
- 📤 File upload
- 📥 File download
- 🔄 Directory synchronization
- ⚡ Incremental transfers
- 🔐 SHA-256 file verification
- 📁 Recursive directory creation
- 🗑️ File and directory deletion
- 📋 Remote filesystem listing
- 🚀 Automatic agent deployment
- 🕒 Ephemeral (agentless-like) execution
- 🧩 Windows and Linux support
- 📦 Standalone agent
- 🐳 Usable with VMs, containers, and physical machines
CrossPilot is designed to be used both manually from the CLI and as a component of automation systems.
CrossPilot uses a controller / agent architecture.
CrossPilot Controller
│
│ TCP
│
┌─────────┴─────────┐
│ │
CrossPilot Agent CrossPilot Agent
│ │
Windows Linux
The controller sends operations to the remote agent.
The agent executes the operation using the operating system's native primitives.
EXEC
PUT
GET
LIST
MKDIR
DELETE
SYNC
The goal is to keep the protocol operating-system independent.
CrossPilot was born to solve a simple problem:
How do you control a remote machine without depending on a specific remote access system?
SSH is excellent for Linux.
WinRM is useful in the Windows ecosystem.
SMB is great for sharing filesystems.
RDP is designed to interact with a desktop.
CrossPilot takes a different approach:
a single protocol for remote system operations.
This makes it possible to build on top of the same agent:
- CLI tools
- provisioning systems
- DevOps automation
- CI/CD
- VM management
- remote machine management
- orchestrators
- development tools
- desktop applications
CrossPilot can run programs and commands on the remote machine.
On Windows it can run, for example:
cmd.exe
PowerShell
.exe
.bat
.cmd
On Linux the backend can use:
/bin/sh
bash
Conceptual example:
crosspilot exec server01 -- "hostname"or:
crosspilot exec server01 -- "powershell Get-Process"The agent starts the process on the remote system and forwards the output to the controller.
CrossPilot supports bidirectional transfer:
Controller ──────── PUT ────────> Agent
Controller <──────── GET ──────── Agent
Example:
crosspilot put ./app.exe server01:/opt/app/app.exeand:
crosspilot get server01:/var/log/app.log ./app.logThe transfer uses a dedicated binary protocol instead of going through shell command encoding.
For large files, CrossPilot can avoid re-transferring data that is already present on the remote system.
The file is split into segments and block signatures are generated.
Local file
│
├── block 1
├── block 2
├── block 3
├── block 4
└── ...
│
▼
Remote signatures
│
▼
Delta generation
│
▼
Transfer of only the
necessary data
This approach is particularly useful for:
- disk images
- large databases
- build artifacts
- application directories
- VMs
- files that change frequently
CrossPilot can synchronize a local directory with a remote directory.
crosspilot sync ./build server01:/opt/myappDuring synchronization, the following are compared:
- path
- element type
- size
- possibly checksum
Elements can be classified as:
NEW
CHANGED
MISSING
IDENTICAL
CONFLICT
Example:
./build/
├── app.exe
├── config.json
└── assets/
├── logo.png
└── index.html
can be synchronized to:
C:\Apps\MyApp\
or:
/opt/myapp/
Synchronization can optionally remove elements from the remote system that no longer exist in the source.
crosspilot sync ./build server01:/opt/myapp --deleteFor destructive operations, the following mode is also available:
crosspilot sync ./build server01:/opt/myapp --dry-runwhich shows the changes without applying them.
CrossPilot uses SHA-256 to verify transfer integrity.
It is possible to verify:
- individual segments
- complete files
- received content
The transfer also uses temporary files:
file.exe.part
The file is made available under its final name only after the transfer completes and is verified.
This prevents a partially transferred file from being left at the destination path.
CrossPilot uses a proprietary binary TCP protocol.
Each message is encapsulated in a frame:
┌──────────┬─────────┬────────┬─────────────┬─────────┐
│ Magic │ Version │ Type │ Payload Len │ Payload │
│ 4 bytes │ 1 byte │ 1 byte │ 4 bytes │ N bytes │
└──────────┴─────────┴────────┴─────────────┴─────────┘
Magic:
DFB1
The protocol supports messages for:
PUT
GET
SIGNATURE
DELTA
ACK
ERROR
META
LIST
MKDIR
DELETE
QUIT
The structure is designed to allow new operations to be added without changing the base framing.
The shell channel also accepts quit/exit to stop a running agent (crosspilot quit), and an ephemeral "agentless-like" mode (--ephemeral): the agent runs the operation, then shuts itself down — nothing is left running on the remote host.
CrossPilot is designed to separate:
Protocol
│
┌─────────┴─────────┐
│ │
Windows backend Linux backend
│ │
▼ ▼
Win32 / cmd POSIX / shell
Task Scheduler systemd
Job Objects process groups
The protocol remains common while operating-system-specific operations are implemented by the respective backend.
This allows the same operating model to be used regardless of the remote system.
The controller can also handle agent bootstrap.
On Windows, deployment can use WinRM to:
- check for the agent's presence
- check the version
- transfer the executable if necessary
- configure the environment
- start the agent
Once the agent is running, normal operations use the CrossPilot protocol.
In this way, WinRM can be used as the initial control plane, while CrossPilot becomes the operational data plane.
Bootstrap
│
WinRM
│
▼
Install Agent
│
▼
CrossPilot TCP
│
┌──────┼──────┐
▼ ▼ ▼
EXEC FILE SYNC
The agent is designed to be distributed as a single executable.
This makes it possible to use it in:
- workstations
- servers
- VMs
- cloud machines
- physical machines
- test environments
- CI/CD
- containers
There is no need to install a complex runtime framework on the remote system.
crosspilot sync ./dist server01:/opt/myapp --deletethen:
crosspilot exec server01 -- "/opt/myapp/start.sh"crosspilot exec win01 -- "powershell Get-Service"Upload:
crosspilot put ./app.exe win01:"C:\Apps\app.exe"crosspilot get server01:/var/log/app.log ./logs/app.logcrosspilot sync ./release server01:/opt/releaseFiles that are already identical can be skipped, and modified files can use incremental transfer.
CrossPilot can be used as a building block for:
- deployment
- provisioning
- updates
- log collection
- artifact management
Build
│
▼
CrossPilot
│
├── Upload
├── Sync
├── Execute
└── Verify
It can be used to manage Windows and Linux VMs without necessarily requiring a guest-specific protocol.
An orchestrator can use CrossPilot as a backend to execute operations on nodes.
CrossPilot does not want to be yet another remote desktop.
It does not want to replace:
- RDP
- SSH
- SMB
- WinRM
Its goal is to provide a simpler, more uniform layer for automation and remote operating system control.
CrossPilot
│
┌──────────┼──────────┐
│ │ │
EXEC FILE SYNC
│ │ │
└──────────┼──────────┘
│
Remote Host
A controller talks to an agent.
The agent translates operations into the language of the operating system.
Building tools like this is fun, but seeing stars is better!
If this tool saved you time or just made your life easier, please drop a star on this repository. It costs you $0.00, but it gives me the fuel (and the dopamine) to keep building and sharing more cool stuff for free.
Go on, click that star. You know you want to! 😉
Pull requests, issues, and contributions are welcome.
Particularly interesting areas are:
- Linux backend
- Windows backend
- protocol security
- transfer performance
- synchronization
- CLI
- API
- cross-platform testing
- documentation
One agent. Any host. Full control.