Device runner

What this is: how Ben runs a task on your own laptop (or on a server) through a small runner program you install and approve. Who it is for: staff who want Ben to work on their machine, admins who enrol devices, and developers who maintain the runner. You will learn: how to enrol a device, what the runner may do, what it asks you, and how to stop or remove it.

What you get

A target says where a request runs. The default is the sandbox. Bill and Ben read the target from your words with fixed rules, never the model. Everything is off until your admin switches device use on.

You say	Target
"on my laptop"	your one enrolled device (you need exactly one device)
"on Sam's laptop"	Sam's device, only if Sam shared it with you
"on the server" or "on main"	a named server, for scripts only
nothing	the sandbox

If the device is not ready, Ben says so. He never falls back to the sandbox without telling you.

Who may use a device

Two checks, and both must pass. Both fail closed.

1. Ownership. The device is yours, or its owner listed you as someone they share it with.
2. A permission. The permission to use a device (strong sign-in, business plan), or the permission to run scripts on servers. See permissions.

A colleague's request always shows a prompt on the owner's screen. Shell commands never run on servers. Scripts never run on devices.

Enrol a device

1. An admin asks for an enrolment code for a person and says whether it is for a device or a server. This needs the permission to enrol devices (or to run scripts on servers, for a server). The code is 8 characters, works once, and expires after 10 minutes. Ben cannot create codes, so a code never passes through the model or a chat channel.
2. On the device, install the runner program with the help of your developer (there is no ready-made installer yet), then enter the code and a name for the device, for example "my-laptop".

The runner proves who it is with a key that is made on your device and never leaves it. It only connects out to Bill and Ben. You open no inbound port. Too many wrong codes in a minute lock that source out for a while.

You can have the runner start when you log in. Run it as your own user, not as an administrator, so prompts reach your screen.

What will be asked

In short: your computer shows each task and nothing runs unless you allow it.

Legend: yellow = a person, blue = Bill & Ben, red dashed = a check or a stop, grey = stored data. Open full size

The runner sorts each command into a risk class on your device.

Class	Examples	What happens
read	listing files, reading files, searching text, from your allowed list	runs silently
write	shell operators, commands that write, version control, anything not on the list	prompt
danger	recursive deletes, admin commands, forced pushes, piping a download into a shell	prompt, and "Allow for this job" is not offered

The prompt shows the full command and who asked. You pick Deny, Allow once or Allow for this job. No answer in 2 minutes is a deny. No desktop session is a deny. A very long command is refused, not shown. Folders on your protected list (for example your SSH and cloud credential folders and keychains) are refused before any prompt.

On a Mac the prompt is a normal dialog (tested). On Windows the box has Yes for Allow for this job, No for Allow once and Cancel for Deny. On Linux it is a standard desktop dialog. The Windows and Linux dialogs are Unverified on real machines. For headless use the runner can ask in the terminal instead.

The command runs with a cleaned environment: only the names you allow are passed on. Output is cleaned of sensitive values and capped in size. Every job writes one line to a log on your device. The request is pinned: a changed command is refused.

Stop it

Action	Who	Effect
Pause	you, on the device	the runner stops connecting until you resume it
Deny in a prompt	you	that one job is refused
Kill switch	admin	all runners are dropped and no new connections are accepted until the admin resumes; runners then reconnect on their own
Revoke	admin, or the device's owner (anyone with the permission to run scripts on servers, for a server)	jobs are cancelled and the runner stops for good
Remove from the device	you, on the device	same effect as revoke

Settings your admin controls

Your admin switches device use on or off for the whole company. Your device has an optional policy file in the runner's folder: a missing file means safe defaults, and an invalid file stops the runner. It sets how prompts are shown, how long they wait, which commands run without asking, which folders are protected, who may share your device, and which scripts a server may run. A server runs only scripts on its allowed list, and without a prompt. The other settings are for devices.

Known gaps

• The device pin covers the call arguments: Built. Earlier notes that said otherwise are stale.
• Unattended tasks cannot use write tools: approvals still apply. Attended chats and meeting tasks work.