Continue local development from a remote AI agent

Reuse the environment where the problem occurs

Suppose a Node.js repository builds on your Mac or Linux workstation but one test is failing. Its dependencies, caches, test data and local services are already configured. You want a remote agent to inspect the failure and propose a small fix. This is an illustrative workflow, not a claim that ADC independently diagnoses code.

The agent reasons in its own environment; the Connector uses the real repository on the target. You avoid recreating that environment solely for this task. A separate cloud sandbox can still be preferable for untrusted code, parallel experiments or tasks that do not need device-specific resources.

Before starting, identify the repository's current uncommitted changes, the test command and any services the test affects. The walkthrough uses npm test as an example; choose the project's actual command. Windows Node and Android Node remain in testing, and Android does not expose this desktop toolset.

Read, patch and run the configured test

Expose the project folder on the target device and create Agent access for the tools the task needs. For editing and tests, both local and account-side policy must permit writes and execution. On the device, register a fixed test template against the project's ROOT_ID from adc-node roots list.

command.template.list only shows the configured commands. test.run defaults to the template named test; it does not infer your framework or discover a test script. Templates let the owner choose the command without granting arbitrary shell access. They are not a sandbox: npm test and its dependencies still run with the device process's operating-system authority.

adc-node roots list
adc-node templates add test --root ROOT_ID --command "npm test" --timeout 300000
adc-node templates list

Call from the agent's environment

Create project-review access in the console for this device and root. Include file.list, file.read, file.search, file.edit or file.patch, command.template.list, test.run, task.status and task.wait as needed, with approvals for side effects. The following calls assume this access already exists. Replace NODE_ID, ROOT_ID and the absolute path with the target's values.

First read the README and relevant source, then review the proposed patch and apply only the intended change. The exact edit depends on the bug, so there is no universal patch to copy. Run the configured test and inspect its terminal output and exit status. Wait again on the returned jobId if the response is still queued or running.

adc login --url https://adc.zioon.tech
adc connect project-review --json
adc invoke file.read --node NODE_ID \
  --args '{"path":"/Users/me/work/project/README.md"}' --wait 4000 --json
adc invoke command.template.list --node NODE_ID \
  --args '{}' --wait 4000 --json
adc invoke test.run --node NODE_ID \
  --args '{"rootId":"ROOT_ID","timeoutMs":300000}' \
  --idempotency-key project-review-test-001 --wait 4000 --json
adc task wait JOB_ID --wait 4000 --json

Know what the workflow verifies

The result should include the intended diff, test output and corresponding task records. A zero exit code supports the selected test's conclusion; it does not prove every behavior is correct. ADC records and routes the calls, while the agent and developer decide whether the change solves the problem.

Revoke or narrow the access when the task is finished. Doing so cannot undo completed edits or external effects. Review the diff before committing; when a test's result is uncertain, follow its original task and reconcile instead of submitting a duplicate under a new key. Requested file contents and command output pass through the chosen service.