From the first device to the first verified tool call

Prepare one known file

This walkthrough uses macOS or glibc Linux and the official HTTPS service. You need an ADC account, outbound connectivity, and permission to install a user-level background service. The desktop installer includes its runtime. Windows Node and Android Node are in testing; use their platform-specific instructions rather than copying Unix paths onto them.

Create a small folder with predictable content. The first goal is to prove that the authorized agent can read this file on this device. No model is needed for the verification: the CLI exercises the same access path that an agent will use.

mkdir -p "$HOME/adc-demo"
printf 'ADC device read verified\n' > "$HOME/adc-demo/README.txt"

Pair the Connector and expose the folder

Sign in to the console and choose Devices → Pair device. Select the target platform and use its generated installation command. The pairing code is one-time and short-lived. Replace PAIRING_CODE below with that code; pairing belongs on the target computer, where the Connector creates its local identity and startup service.

Set local access to selected folders and add the demo folder as read-only. Inspect status and roots. Keep the returned nodeId and root ID; if the folder already exists in the list, reuse its root ID. Success at this stage means the Connector is online and advertises the intended folder, not that an agent is already authorized.

curl -fsSL https://adc.zioon.tech/downloads/node/install.sh | sh -s -- \
  --url https://adc.zioon.tech --code 'PAIRING_CODE'
adc-node access selected
adc-node roots add "$HOME/adc-demo" --label Demo --read-only
adc-node status
adc-node roots list

Authorize a caller separately

On the computer or cloud environment where your agent will run, install the CLI if necessary using the installer with --cli-only. Log in, create an access named first-agent, and bind the CLI to it. Pairing connects a device to your account; this separate access determines what the caller can do.

Replace NODE_ID and ROOT_ID with the identifiers from the previous step. The explicit tool list allows reading and following tasks while keeping write and command tools out. You can make the same selection in the console's Agent access form. Keep the local folder read-only as well: neither side can widen the other's restriction.

curl -fsSL https://adc.zioon.tech/downloads/node/install.sh | sh -s -- --cli-only
adc login --url https://adc.zioon.tech
adc access create --name first-agent --devices NODE_ID --folders ROOT_ID \
  --tools device.list,device.status,file.list,file.read,file.search,task.status,task.wait \
  --profile read-only --approval never --json
adc connect first-agent --json
adc node list --json

Read the file and check the task

Use the absolute device path from the root listing, including the target user's real home directory. adc node list should show the authorized target, and file.read should return the line ADC device read verified. Inspect the terminal status and matching Activity record. A queued or running response only means more waiting is needed.

Replace JOB_ID with the returned task ID when needed. If the device is missing, check local status and the access's device selection. If reading is denied, check both folder selections, the read tool and the absolute path. Do not solve a setup mismatch by opening the whole filesystem.

adc invoke file.read --node NODE_ID \
  --args '{"path":"/Users/me/adc-demo/README.txt"}' --wait 4000 --json
adc task wait JOB_ID --wait 4000 --json

Expand only after the read path works

Once this succeeds, connect the same access to an MCP client or your agent's CLI integration. Add a separate writable project folder or a fixed test template when the task requires it, and choose approvals for side effects. A successful file read verifies routing and read permission; it does not verify shell isolation or every Android capability.