---
title: "Your own machine · intentic docs"
description: "Sync a folder into the sandbox, let the agent operate your computer, or drive its agents from Zed or JetBrains over ACP."
url: "https://intentic.dev/docs/your-machine/"
updated: "2026-08-10"
---

Run a sandbox

# Your own machine

Three connections between a sandbox and a computer you own — your files going in, the agent reaching out, and your editor driving the agents. They point in different directions, which is the thing to get straight.

**On this page (5 sections)**

- [Desktop sync](#desktop-sync)
- [Letting the agent use your computer](#letting-the-agent-use-your-computer)
- [The editor bridge](#the-editor-bridge)
- [Servers, as opposed to computers](#servers-as-opposed-to-computers)
- [Next](#next)

All three live on **Sandbox → Computers**.

| Connection | Direction |
| --- | --- |
| **Desktop sync** | Your folder appears in the sandbox's workspace, and the sandbox's ports appear on your localhost. |
| **A connected computer** | The agent operates *your* machine — runs commands, handles files, sees the screen. |
| **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 on your machine 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 running in the sandbox opens in your own browser at the address you'd 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 computers 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 computer while the first holds sync.

Disabling revokes the machine's access but leaves the agent installed — removing it is `intentic-sync uninstall` on that machine, so nothing uninstalls software behind your back.

## Letting the agent use your computer

The opposite direction: add your machine as a capability and the agent can work *on* it. Your computer dials the sandbox rather than the other way round — a personal machine sits behind NAT with a closing lid, so it can only ever 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 deliberately 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 and restart the sandboxes on this machine — 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. And the switches are enforced **on your machine**, not in the sandbox: they're pushed down on every connect and the agent on your computer refuses out-of-scope calls itself. So a compromised sandbox, or an agent talked into something by a page it read, still cannot exceed what you ticked.

## 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:

Zed → settings.json

```json
{
 "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 — and it is scoped to one conversation: the bridge can run a turn, answer a question it parked on, read transcripts and search the tree, and it deliberately cannot see the fleet or land work. Treat it like a password anyway, because within that scope it can edit files and run commands here. The card lists *every* control token against the sandbox rather than only the ones it minted, so a revoke surface can't hide the token somebody made elsewhere.

## Servers, as opposed to computers

A server is something the sandbox *dials*; a computer of yours is something that dials the sandbox — and the difference you feel is that one of them is the machine you're sitting at. Remote machines over SSH and private networks over VPN are ordinary capabilities; see [Capabilities](https://intentic.dev/docs/capabilities/).

## Next

- [Access & sharing](https://intentic.dev/docs/access/): who else may connect a machine, and what a member is offered.
- [HTTP API](https://intentic.dev/docs/sandbox-api/): control tokens, their scopes, and minting one without the UI.

More in Run a sandbox

[Previous ← Access & sharing](https://intentic.dev/docs/access/)