Cloud coding agents: from local setup to a tested pull request

The agent has finished editing. Now it needs to install dependencies, start the database, run the tests and open a browser. Those steps turn a draft edit into something you can check. They also tie up your laptop.

A cloud coding agent runs that work on another machine. With Hoplite cloud agents, each thread gets an isolated sandbox with your cloned repository, your environment variables, your setup script, and a browser. You describe a task, the agent works through it, and you review the diff and the running app. The sandbox documentation explains what persists and how runtimes recover.

A good first goal is a small pull request you can verify. A large task makes it harder to tell whether you're evaluating the agent, the setup or an ambiguous brief.

Prepare the repository once

Connect the Hoplite GitHub App and grant access to the repository you want to use. Select that repository to create a project, then configure how the project installs dependencies and starts the app.

These commands live in .hoplite/settings.json, with project settings able to override them. Add the required environment variables in Project settings. Use dev credentials and a database the sandbox can reach. The agent cannot reach a database running on your laptop through a local .env.

A working setup should survive a fresh checkout. If it depends on something you installed by hand once, record that step before delegating work. The agent-ready repository guide covers setup, run commands, secrets and standing instructions.

You can also import local session history and personal skills with hoplite onboard. MCP import copies server addresses by default. Moving credentials needs a separate confirmation. Import brings useful context with it, but it doesn't replace a reproducible development environment. See the import documentation.

Choose a task with a visible finish

Take an account settings app as an example. This brief works well for a first run:

On the profile page, submitting an empty display name currently clears the saved name. Reject empty or whitespace-only input and show an inline error. Keep the existing save flow and API contract. Add a regression test, run the relevant checks and verify the form in a browser. Open a draft PR and leave merging to me.

This gives the agent a behavior to change and a way to check it. It also keeps the scope small enough for a reviewer to follow without needing the full product backstory.

Start a thread from the intended base branch. Wait until setup finishes before you follow the implementation. If the agent keeps retrying a missing runtime install, fix the environment.

Let the cloud do the execution

The agent can edit files, run checks and start a preview in the sandbox. The activity timeline records its tool calls. The thread pauses sensitive operations for approval, including shell commands and protected file changes. A waiting thread needs your input before it can continue.

Once the task runs remotely, those processes leave your laptop. You can close it and the work stays in the cloud. Approvals, failures and the workspace lifecycle can still pause it. Follow the thread's state when you return.

The quickstart walks through creating the thread and opening its draft PR. If you want to move an existing local task instead, use the handoff workflow.

Review the change and the evidence together

For the profile example, check if the validation follows the existing form conventions. Read the new test. Then open the preview and try a blank value, a whitespace-only value, and a valid name.

Ask the agent which commands passed and which checks it could not finish. A screenshot can show the error message; it cannot prove that a valid name survives a reload. The evidence should match the behavior you're changing.

The PR rail shows checks and review comments. You can attach reviewer comments to the thread and ask the agent to address them. Keep the first run under manual review while you learn which project settings and instructions need to change.

Start with one reproducible bug. When that PR is easy to review and the preview works, you have a workflow you can reuse.