A remote executor is a Metnos executor that is not launched on the server, but on a device registered to the same user, such as a Windows PC or Linux laptop. The server remains the decision point: it checks whether the action is allowed, signs the payload, receives the result and writes the audit trail.
The client supports pairing guided by the interface, contained execution on Linux and Windows, process-tree termination at the deadline, controlled restart if sandbox construction does not return, single-instance locking, and server-side revocation.
Metnos is designed as a household system: many data live on the server, but not all of them. A document may sit on a laptop, a work folder on a Windows PC, a screen or an application may exist only there. Remote executors bring a controlled part of the catalog to the place where the data actually live, without turning each machine into a second Metnos.
The asymmetry is deliberate: the device executes, but it does not decide. The
server keeps policy, Vaglio, executor selection, signing, the device registry and
audit. The remote client, metnos-client, polls the server, verifies
the signature of the received job, runs it inside the containment available for
its OS and returns a signed result.
Each device has its own Ed25519 identity. Admission happens through a single-use code generated by the server: the client consumes it, registers the device public key and receives the server public key for pinning. From that point on the device is not "an open browser": it is a known, revocable and recognisable machine.
The detailed flow is described in Identity and pairing, ch. 6. The essential parts are: short token, one-time consume, unique device fingerprint, periodic heartbeat and explicit revocation from the admin panel.
An executor does not become remote by accident. The loader reads its manifest: allowed platforms, capabilities, signature and optional placement section. Only when the contract is compatible may the runtime assign the job to a device. Otherwise the executor stays local or is refused with an explicit error.
| Check | Why it matters |
|---|---|
platforms | Prevents sending to Windows an executor written only for Linux, or the reverse. |
| server signature | The client runs only code that matches what the server signed. |
| capabilities | Policy and Vaglio stay server-side; the device does not widen permissions. |
| placement | States whether the job may stay on the server or requires a specific device. |
A selected provider backend is always bound to the server: network access,
credential home, and placement derive from the same effective
provider:access capability. A local backend of the same executor does not
inherit that restriction and remains device-eligible when
placement.device_ok allows it.
Browser, credential, and ACL-sharing authority are separate in the canonical
registry: network:sites restricts a session to approved origins,
auth.password_storage restricts reads to the credential scope, and
drive:permissions identifies a critical remote grant. All
*_sites executors remain server-only.
Metnos-managed resources also use separate authority:
metnos:read, metnos:write,
metnos:create, and the
metnos:credentials_metadata_only constraint. The latter prevents
vault executors from returning secrets to the planner.
In compound flows, presentation follows the terminal operation: when a search
ends by creating an archive, chat returns an artifact-and-folder receipt rather
than the technical compress_files table. Legitimate tables stay
inside the message bubble and scroll horizontally when a path or URL cannot be
broken without losing information.
The table above tells you whether an executor may leave the server. The
practical question remains: on which machine does a command you type in chat
actually run? Metnos answers with no panels and no manual toggles — it works it
out from the sentence itself. We call destination the machine where the next
command will run: either the server where Metnos lives
or one of the PCs you have paired, that is, registered once through the pairing
flow. Each paired PC has a name you chose (for example OFFICE-LAPTOP)
and belongs to a user: the server knows which devices are yours.
The conversation below shows a single chat whose destination changes turn after turn. On the right: the three steps by which Metnos decides where to run, the two guarantees, and a diagram of the server / PC fork.
How the device is recognised. The target PC is identified by its name, not by where the connection comes from. Identifying it from the network origin (the IP address) would be unreliable: through a public tunnel the server may see only the ingress address, and a Telegram message has no originating PC behind it. That is why the anchor is the device name — matched against the real names of your paired PCs — and not the network fingerprint. A name dropped mid-sentence, without a locative preposition to anchor it, does not move the destination.
The natural operational point is /admin/devices: the server shows
registered devices and can issue a join link. If the user opens the UI directly
on the server, there is nothing to install: local executors are already available.
If the UI is instead running on a PC different from the server, the page can offer
the installer for the current platform and show registration progress.
The click does not give special privileges to the browser: on Windows it downloads
MetnosClientSetup.cmd, which installs and starts metnos-client
as a persistent operating-system process. The UI observes the join: token issued,
client registered, heartbeat alive, client version, last error.
/admin/devices) and select the user who
will own the PC.The link is temporary and intended for one pairing. If the PC is already listed, inspect the existing device before generating another link.
On the Linux server the canonical sandbox is bwrap. On a remote
device containment is chosen by the client according to the operating system, but
the interface is single: run this payload with these limits and return stdout,
stderr, exit code, timeout and containment metadata.
| System | Current containment | Note |
|---|---|---|
| Linux | Client-side bwrap when available | Mount and PID namespaces, a restricted filesystem, and a separate network when it is not requested. Custom Landlock and seccomp are not implemented. |
| Windows | AppContainer inside a Job Object | Targeted ACLs for absolute paths; when a relative path cannot be anchored before spawn, the client explicitly falls back to the Job Object instead of attempting ambiguous ACLs. |
| macOS | No native sandbox | The common Unix path runs without an operating-system wrapper and reports sandbox:"none". |
See sandbox, ch. 10 for the per-OS detail. Remote results always report the containment actually applied. A separate watchdog terminates the client, leaving restart to its supervisor, if sandbox construction does not return within the deadline plus a bounded grace period.
The channel is built for an imperfect home network. The client periodically polls the server, so it does not require open ports on the PC. Each invocation has idempotency and a deadline: if the network drops, the server can distinguish between a job not yet picked up, a job in progress and a result already delivered. If a client is stuck, the local lock prevents a second concurrent instance; if a job exceeds its timeout, the client kills the process tree. Heartbeat runs in a separate task, so the device remains observable even while it is preparing its own execution environment.
Revocation is server-side: the revoked device gets an error on polling or heartbeat and stops receiving work. The server does not need to trust that the old client will behave well: it simply stops assigning payloads to it.
Remote executors do not mean "run arbitrary code on the PC". They mean: run only signed executors, compatible with the platform, admitted by policy and sufficiently contained by the client. The admitted mutating executors (file write and move) carry their own undo: reverting an operation executed on a device runs on that same device, never on the server. Remote deletion is admitted as well: the backup (blob) is written on the device before removal, and undo restores it on that same device.
none must not be described as isolated.