Cloud coding agents: how remote work continues and recovers

Find out where the commands actually run

A browser chat interface does not establish where code executes. Ask where the repository is checked out, where package installs run, and which machine serves the preview. A local coding tool connected to a hosted model can still depend on your laptop for every shell command.

In a remote execution setup, closing the laptop does not directly stop a process running on the remote machine. The service may still pause idle environments, enforce task limits, run out of credits, or wait for approval. Find those conditions before assigning work you expect to finish unattended.

For Uno, the session environment description places commands, tests, and browsers in a cloud computer per session. That describes the execution location. It does not promise unlimited running time or guarantee that a task can proceed without your input.

Give unattended work a stopping point

Choose a task with observable completion and bounded authority. Updating a repository's broken documentation links is easier to hand off than "improve the product." Specify what the agent can change, how it should validate the result, and what requires a decision.

Goal: Repair broken internal links in the setup guide.
Scope: Documentation files only; preserve current instructions.
Check: Run the repository's documentation link checker.
Deliver: Patch, check results, and any unresolved destinations.
Stop and ask: A destination moved and its replacement is unclear.
Release: Prepare the change for review; do not publish it.

Keep the repository revision and relevant commands with the task. If setup depends on credentials or a private service, confirm that access before walking away. A task waiting for a missing secret can occupy a remote environment without making progress.

Ask for a checkpoint when a task is long enough that interruption would be expensive. It should say what changed, which checks ran, and what remains. Store important outputs in the team's durable review system according to its normal rules; do not assume every scratch file will survive environment replacement.

Separate environment readiness from task progress

Several events can happen before the agent performs useful work. The service accepts the request, prepares the environment, starts execution, and may later wait for a decision. A ready machine says little about which step of the task has finished.

Uno's MCP session workflow distinguishes queued (accepted), running, and terminal turn states. Follow the returned conversation and read its messages before reporting a result. The same principle is useful in the web interface: inspect progress and the agent's output.

A useful progress update names the latest completed action and the next dependency. "Installed packages; running the documentation checker" tells you more than a spinner. If the last action has failed, inspect the error before assuming that more waiting will resolve it.

For programmatic delegation, save the accepted operation's identifiers. A client timeout leaves acceptance uncertain. Check the original request using the service's recovery contract before creating a second task that could perform the same writes.

Waking a machine and starting an app are separate actions

A sandbox can be available while its application server is stopped. A preview address can also exist while nothing is listening on the registered port. Treat machine status, process status, and an actual HTTP response as separate checks.

In Uno, waking a sandbox starts the environment; it does not restart app-server processes. If a preview does not respond after waking, return to the session and have the agent check the process, its startup command, and the expected port. Uno's tool catalog exposes sandbox status, wake, and preview access as separate operations.

Keep launch instructions reproducible in the repository. Name the command, required setup, and expected address without embedding credentials. If the app uses background workers or a local database, include those dependencies so recovery does not produce a half-working preview.

When work resumes, ask the agent to inspect existing changes before starting implementation again. Reinstalling packages may be harmless; recreating already-written data or opening duplicate pull requests can create unnecessary repair work.

Ask about the limits that affect your task

Check the service's current pricing and capacity alongside its technical behavior. A short edit with a large build can have different resource needs from a long documentation task. Compare the cost of the whole attempt, including setup, retries, and reviewer time.

• How long can an active task execute, and what happens at the limit?
• When does an idle environment pause, and what is preserved?
• What happens if the model call or repository connection fails?
• Which actions need a person, and where does the agent wait?
• Can a reviewer recover the patch if the environment disappears?

Separate environments also need separate test data when they use the same external services. A cloud agent can interfere with another task through a shared database even though their processes and local ports are isolated. See the isolation guide before increasing concurrency.

Run one recovery exercise before relying on it

Use a disposable task and a non-production environment. Start work, confirm execution, leave the client, and return to inspect the recorded result. Separately test the service's supported pause and resume flow, then check whether its app preview needs to be started again.

Record what survived and the steps needed to continue. Review the patch and checks using the same verification standard you apply to local work. The trial gives your team a concrete recovery procedure for that setup; repeat it when the provider or environment configuration changes.