Your own machine
Four connections between a sandbox and a device you own: files going in, the agent reaching out, a runner executing there, and your editor driving the agents. They point in different directions and grant different powers.
On this page(7 sections)
The four connections
All four live on Sandbox → Devices.
| Connection | Direction |
|---|---|
| Desktop sync | Your folder appears in the sandbox's workspace, and the sandbox's ports appear on your localhost. |
| A connected device | The agent operates your machine: runs commands, handles files, sees the screen. |
| A runner | The parent sends an isolated turn to a sandbox container on this device; review and landing stay at the parent. |
| The editor bridge | Your editor drives the sandbox's agents, with the transcript in your editor's own chat panel. |
Desktop sync
Pick a folder, press Enable, and you get a one-liner carrying a single-use pairing token. Run it and a small resident agent installs, doing two things: keeping that folder in step with the sandbox's workspace, and mirroring the sandbox's ports onto your localhost, so a dev server there opens in your browser at the address you would expect.
There is no Google sign-in on the laptop. The pairing token is the whole exchange, and it is single-use.
Two modes, and which you get depends on who you are:
- Sync: files and ports. Owner only, and one machine at a time: two devices writing the same workspace is not a thing anyone wants.
- Mirror: ports only, on any number of machines. What a member is offered, and what an owner can add on a second device while the first holds sync.
Disabling revokes the machine's access but leaves the agent installed: removing it is intentic-machine sync uninstall on that machine, so nothing uninstalls software behind your back.
Letting the agent use your device
The opposite direction: add your machine as a capability and the agent can work on it. Your device dials the sandbox rather than the reverse: a personal machine sits behind NAT with a closing lid, so it can only be the side that connects, even though it is the side being asked.
What it may do is a set of switches on the machine's card, and the grants are narrow by default:
| Switch | Default | Grants |
|---|---|---|
| Run commands | on | A real shell: PowerShell on Windows, your login shell elsewhere. Off leaves files and screen only. |
| See the screen | on | Screenshots. Off refuses them and says so, rather than returning a black frame. |
| Create and change files | off | The write half. Reads inside the allowed folders are always permitted. |
| Use the mouse and keyboard | off | GUI work, for things with no command-line way in. Its own switch because looking and touching are not the same permission: a screenshot is bounded by what's on screen, one click can confirm a dialog nobody read. |
| Manage sandboxes | off | Start, stop, restart and resize the sandboxes on this machine (their memory and CPU caps, privileged, GPU), and move them between images: narrower than a shell, and named rather than improvised. |
| Remove a sandbox | off | Separate again, because everything the switch above grants is undone by doing it again and this is undone by nothing. |
File access is bounded to folders you name: your home directory if you name none. The switches are enforced on your machine, not in the sandbox: they are pushed down on every connect and the agent on your device refuses out-of-scope calls itself. A compromised sandbox, or an agent talked into something by a page it read, cannot exceed what you ticked.
Windows and WSL
A Windows PC and the WSL distros on it are one computer with several environments: Windows itself, and each distro, every one of them with its own agent, its own card and its own switches. Connect the Windows side first; its page then lists the distros it has and offers to connect each one, with the command in PowerShell rather than the distro's own terminal. Once both are connected they appear as one machine here, with each side's state on its own line and every sandbox listed once, since Docker Desktop's engine serves both sides.
The agent is told the two are one PC and how to cross between them: run_command takes in: "wsl:<distro>"on the Windows side and in: "windows" inside a distro, so a Linux command never has to be quoted through PowerShell. The screen, the GUI and the clipboard are always the Windows side's.
Using the device as a runner
A runner is different from letting an agent operate the host. It is a sandbox container that uses the machine's compute to execute an isolated conversation; the agent works inside that container, not across the host's files or desktop. Creating and updating one rides the connected device's Manage sandboxes grant, without granting shell, screen or file access.
Add one under Runners for this sandbox on the device's card, then choose it from a new agent's Where this runs picker. The parent sandbox remains the owner of the conversation, transcript, branch mirror, diff and land door. See Remote runners for workspace sync, environment parity, credentials and failure behavior.
The editor bridge
Drive this sandbox's agents from Zed, JetBrains, or any editor speaking the Agent Client Protocol. Mint a token on the Editor bridge card and paste the snippet it generates into your editor's agent settings:
{
"agent_servers": {
"intentic": {
"type": "custom",
"command": "npx",
"args": ["@intentic/acp-bridge"],
"env": {
"INTENTIC_SANDBOX_URL": "https://sandbox-<id>.<zone>",
"INTENTIC_CONTROL_TOKEN": "ict_…"
}
}
}
}Then open your synced folder as the project, so the files the agent edits and the diffs it shows line up with what your editor has open.
The token is shown once. The sandbox stores only its hash, scoped to one conversation. The bridge can run a turn, answer a parked question, read transcripts and search the tree; it cannot see the fleet or land work. Treat it like a password anyway, because within that scope it edits files and runs commands. Every token against the sandbox, this one included, is listed and revoked under Sandbox → Access → API tokens, whichever card minted it, so a revoke surface can't hide the token somebody made elsewhere.
Servers, as opposed to devices
A server is something the sandbox dials; a device of yours dials the sandbox, and the difference you feel is that one of them is the machine you are sitting at. Remote machines over SSH and private networks over VPN are ordinary capabilities; see Capabilities.
Related pages
- Remote runners: executing conversations on this device without moving control.
- Access & sharing: who else may connect a machine, and what a member is offered.
- Authorising a call: control tokens, their scopes, and minting one without the UI.
- Guide: where your code goes: whose machine holds the checkout and whose account holds the keys, across the field.