Coding agents in the cloud

Which coding agents are installed?

Six agent harnesses ship in every sandbox. Sandboxer's integrated agents docs list them by the provider name you pass:

The agents use your own provider keys, which you add on the dashboard's Agents page. Model usage is billed by that provider, separately from Sandboxer's machine time.

How do you give an agent a task?

Send a prompt with sbx prompt, the API or an SDK. Sandboxer starts the harness in the right directory with your keys, records its output as structured events, and keeps the session so the next prompt continues the thread.

sbx prompt "Fix the failing tests and commit"
sbx prompt <sandbox-id> --provider codex "Refactor the auth module"
sbx events <sandbox-id> --follow

The API call returns at once with a prompt id and a conversation id. You can poll for the result or stream events, including over server-sent events. The agent runs as user in /home/user.

Can you steer an agent while it works?

Yes. You can queue another task, add an instruction mid-turn, or stop the turn:

One sandbox can also run several conversations at once, each with its own harness process. Conversations survive stop, resume and fork.

Why run a coding agent in a VM instead of on your laptop?

A cloud VM keeps running unattended, can be thrown away, and gives the agent real tools. Sandboxer's guide on Claude Code sandbox mode, Docker or a cloud VM suggests a cloud VM for unattended runs, untrusted repos, work that needs Docker or KVM, and tasks that must continue while your laptop sleeps. For everyday work on your own machine, it notes Claude Code's built-in sandbox can be enough.

Running an agent without permission prompts is a related case. Sandboxer's guide on skipping permissions says to do it only in a disposable machine with no access to your laptop or production credentials, as a non-root user, and to keep the output on a branch you review.

How do you make every agent behave the same way?

Harnesses read their normal config files from the home directory, such as CLAUDE.md, AGENTS.md, MCP server configs, skills and settings. Commit those to your repo, or bake them into a named snapshot, and every sandbox started from it behaves alike.

sbx snapshot <sandbox-id> agent-ready
sbx new --from agent-ready

You can also bring your own agent: install it, run it as a systemd service or a detached command, and talk to it through a hosted port or files. To run many agents at once, see agent swarms.

How do you get the agent's work back?

Most teams have the agent push a branch and open a pull request. Sandboxer's guides show two ways:

• Issue to pull request: a no-env sandbox with one short-lived GitHub token clones, branches, runs the agent and tests, and opens the PR with gh.
• Background coding agent: workers pull the commit back as a git bundle and push it with the service's own credentials, so the sandbox never holds them.