docs: Continue cloud handoff work in the Console

The handoff guide kept cloud work in the CLI and required saving a template ID during the move. Continue the agent task in the Console, explain the terminal redraw workaround, and identify the backing template during cleanup. Update the live verification checklist to match.
This commit is contained in:
David Karlsson committed 2026-10-30 13:34:58 +00:00
1 parent e56d61ad17
commit f4f44b4282
2 files changed
+42 -30

No files matched your search

@@ -83,11 +83,11 @@ Guide: [Continue local work in the cloud](../../content/manuals/agentic-platform
| Step 1: bounded prompt, baseline, and credential removal | HANDOFF.md records the full matching Git revision, clean tree, project path, and remaining task without starting the review. No application files change or dependencies install. Review filesystem credential files before capture and remove them without recording secrets in evidence. | Pending | Pending |
| Step 2: move command and timeout support | Exact move command succeeds with a two-hour Stop action or fails explicitly if stopping is unsupported. Local source stops for capture; a distinct cloud destination and backing template ID are reported. The template contains the captured HANDOFF.md. Record command output and supported options. | Pending | Pending |
| Step 2: transfer boundaries | Destination contains filesystem files, but local processes, memory, sockets, host mounts, clone-mode volumes, managed secrets, and local network rules aren't transferred. Use disposable non-sensitive fixtures for applicable boundaries and record any boundary not exercised as pending. Verify documented TCP port republication/warning behavior separately on disposable resources. | Pending | Pending |
| Step 3: transferred handoff and destination settings | The exec cat command succeeds using the printed sbx_-prefixed ID. The handoff file contains the recorded baseline, project path, and remaining task. Platform, size, expiration, cloud credential, and destination policy are correct; no unintended ports remain. | Pending | Pending |
| Step 3: run and restart the agent | Run starts the cloud agent using destination credentials and policy. Agent confirms the baseline and completes only the saved task, without an application run. The local agent process hasn't transferred. | Pending | Pending |
| Step 4: detach, continue, and run after stop | Ctrl+\ detaches without ending cloud work. Agent continues while the client is disconnected until timeout. No work runs while stopped; run resumes the stopped destination and starts a fresh timer. | Pending | Pending |
| Step 3: transferred handoff and destination settings | The moved destination appears in Console under the same account and can be selected by its printed sbx_-prefixed ID. An additional browser shell can read HANDOFF.md with cat. The handoff file contains the recorded baseline, project path, and remaining task. Platform, size, expiration, cloud credential, and destination policy are correct; no unintended ports remain. | Pending | Pending |
| Step 3: browser terminal and agent restart | The moved sandbox opens an agent terminal in Console using destination credentials and policy; record any startup steps missing from the guide. Agent confirms the baseline and completes only the saved task, without an application run. The local agent process hasn't transferred. | Pending | Pending |
| Step 4: browser disconnect, reconnect, and resume after stop | Closing the browser leaves cloud work running until timeout. Reopening the destination reconnects to the agent; resizing the browser redraws the interface if it appears stuck. No work runs while stopped; Restore to connect resumes the destination and starts a fresh timer. Record whether the rendering workaround is needed and effective. | Pending | Pending |
| Step 4: retrieve and verify artifacts | Both cp commands succeed and local copies contain the matching baseline, build/startup explanation, listening port, one recommendation with source references, and limitations. Compare the report with the source; record corrections rather than accepting agent claims as test evidence. | Pending | Pending |
| Step 5: remove both sandboxes and the backing template, or retain a stopped destination | Sandbox removal succeeds before template removal; local/cloud sandbox lists and the cloud template list confirm absence after local copies are verified. Confirm the template persists if only its sandbox is removed. If retaining the destination, confirm stopped status, expiration after resume, file retention, and billing guidance. Remove all disposable test resources. | Pending | Pending |
| Step 5: remove both sandboxes and the backing template, or retain a stopped destination | Inspect identifies the backing template; template ls lists it and its ID, without requiring an ID saved during the move. Confirm the matching moved-handoff-local entry before removal. Sandbox removal succeeds before template removal; local/cloud sandbox lists and the cloud template list confirm absence after local copies are verified. Confirm the template persists if only its sandbox is removed. If retaining the destination, confirm stopped status, expiration after resume, file retention, and billing guidance. Remove all disposable test resources. | Pending | Pending |
## Publication decision
@@ -76,10 +76,9 @@ $ sbx move handoff-local --to cloud --ttl 2h --on-timeout stop
```
The move stops the local source for capture and creates a separate destination.
Use its printed `sbx_`-prefixed ID in place of `<CLOUD_ID>`. Also save the
printed template ID as `<TEMPLATE_ID>` for cleanup. The template is the
filesystem image used to create the destination, including `HANDOFF.md`. It
remains after you remove the sandbox.
Use its printed `sbx_`-prefixed ID in place of `<CLOUD_ID>`. The move also creates
a template: the filesystem image used to create the destination, including
`HANDOFF.md`. It remains after you remove the sandbox.
Cloud sandboxes support both `linux/amd64` and `linux/arm64`. The destination
matches your local sandbox's architecture; a move doesn't convert between them.
@@ -95,27 +94,29 @@ Local network rules don't transfer either. Published TCP sandbox ports can be
republished with cloud URLs; rejected ports produce warnings. See
[Move a sandbox](/manuals/ai/sandboxes/cloud/move.md) for transfer details.
## 3. Verify the destination and restart the agent
## 3. Continue in the Console
Use the destination ID printed by the move to read the transferred handoff:
Open the [Console](https://agentic-platform.docker.com) and sign in with the
same Docker account you used for the CLI. Open **Sandboxes** and select the
destination using the ID printed by the move. Use its browser terminal to
continue the task; the local agent process wasn't transferred.
```console
$ sbx --cloud exec <CLOUD_ID> cat /home/agent/workspace/HANDOFF.md
```
Expect the recorded baseline, project path, and remaining task. Before starting
work, confirm the move's reported architecture, compute size, and expiration
match your expectations. Check that your cloud Anthropic credential is set.
This task needs no published ports; remove any unintended exposure. Verify the
Before starting work, confirm the destination's architecture, compute size,
and expiration match your expectations. Check that your cloud Anthropic
credential is set. This task needs no published ports; remove any unintended
exposure. Verify the
[cloud network policy](/manuals/ai/sandboxes/cloud/network-policy.md) permits
the model provider; local network rules don't transfer.
Restart the agent explicitly; its local process wasn't transferred:
In an additional shell, check the transferred handoff:
```console
$ sbx --cloud run <CLOUD_ID>
$ cat /home/agent/workspace/HANDOFF.md
```
Expect the recorded baseline, project path, and remaining task. Return to the
agent's terminal to restart the work.
Give it this prompt:
```text
@@ -126,18 +127,19 @@ Complete only the recorded task and save /home/agent/workspace/review.md.
## 4. Disconnect and retrieve the result
Once the agent starts, press `Ctrl+\` to detach. The cloud agent can continue
while your computer is disconnected. The timer still applies; no further work
runs after the sandbox stops until you resume it.
Once the agent starts, close the browser tab to disconnect. The cloud agent
can continue while your computer is disconnected. The timer still applies;
no further work runs after the sandbox stops until you resume it.
Return from your computer's terminal:
Return to **Sandboxes** in the Console and reopen the destination. If it is
paused, select **Restore to connect**. Resuming starts a fresh timer. Review
the agent's response in the browser terminal.
```console
$ sbx --cloud run <CLOUD_ID>
```
> [!TIP]
> If the terminal appears stuck after reconnecting, try resizing it by resizing
> your browser window. This can make the agent interface redraw.
Review the agent's response. Running resumes a stopped sandbox and starts a
fresh timer. When the report is ready, detach with `Ctrl+\` and copy both files:
When the report is ready, return to your computer's terminal and copy both files:
```console
$ sbx --cloud ttl <CLOUD_ID>
@@ -154,7 +156,17 @@ results is what brings them back to your computer.
## 5. Clean up both sandboxes
After verifying your saved files, remove the destination, its template, and the
local source. Delete the cloud sandbox before removing its backing template:
local source. First inspect the destination to identify its backing template,
then list the templates. Find the matching entry, typically named
`moved-handoff-local-<SUFFIX>`, and use its ID as `<TEMPLATE_ID>`. Check the ID
against the inspected sandbox so you remove only this move's snapshot:
```console
$ sbx --cloud inspect <CLOUD_ID>
$ sbx --cloud template ls
```
Delete the cloud sandbox before removing its backing template:
```console
$ sbx --cloud rm <CLOUD_ID>