Testing with Computer Use and video recordings

Agents don’t just write code — with Computer Use enabled they can drive a real desktop GUI in an isolated sandbox, record everything they do, and hand you a trimmed, annotated video as concrete proof of the result.

This page explains when to use Computer Use with recordings, how the recording pipeline works, where your recordings end up, what the finished video contains, and how to handle common recording failures.

When to use it

Computer Use with recordings is useful in three situations:

• UI change evidence — After a code change lands, ask an agent to boot the app, exercise the affected surface, and record the session. You get a video showing the change works without running the app yourself.
• End-to-end QA of existing flows — Run an agent through a critical workflow (for example, Warp’s onboarding flow or a multi-step form) and capture the full interaction as a single clip for review or a regression archive.
• Reproducing a bug — Ask an agent to reproduce the exact steps from a bug report and record them. The resulting video is the definitive reproduction artifact — shareable, time-stamped, and independent of local environment differences.

You don’t need to ask the agent to record explicitly. Prompts like “test this change”, “verify the fix works”, or “produce evidence” naturally lead an agent with Computer Use enabled to start and stop a recording as part of its workflow.

How it works

1. Enable Computer Use. The agent needs Computer Use enabled for its run. See the Computer Use page for how to enable it via the Warp app, the CLI, or the API.
2. Agent starts recording. Once Computer Use is active, the agent begins a screen capture inside the sandbox. The recording is gated by your session’s Computer Use approval. If you’ve already approved Computer Use for the run, recording starts automatically without a separate prompt.
3. Agent exercises the UI. The agent takes screenshots, clicks, types, scrolls, and drives the interface. Each successful interaction is tracked: when it started, when it finished, what actions it contained, and where the cursor moved.
4. Agent stops and processes. When the task is complete (or when the recording’s configured time or size limit is reached), the agent stops capture. Before upload, the recording is post-processed: idle and thinking gaps are cut, leaving only the windows where real interaction happened, and action overlays are burned in so the video is annotated.
5. Artifact is published. The processed video is uploaded as a run artifact and made available in the conversation, on the run page, and in the pull request description when the agent opens or updates a PR.

Where to find recordings

In Warp

After the agent finishes its Computer Use session, any video recording appears as a block in the conversation. Clicking the block opens the full conversation view alongside the recording artifact. If the recording was produced by a cloud agent run, you can also access it by opening that run’s transcript as a cloud-synced conversation.

On the Oz web run page

Cloud agent runs are listed on the Runs page of the Oz web app. Open a run to see its artifacts section, which lists any video recordings produced during that run. You can play the video directly from the run page or download it.

On pull requests

When a cloud agent run produces video recordings, those recordings are attached to the PR description as links alongside the agent’s summary. The attachment is automatic once the recording artifact is associated with the run — no extra steps are needed from you.

What’s in a recording

The finished video is not raw screen capture. After the agent stops recording, the client post-processes the video before uploading it:

• Smart cut of idle and thinking time. Gaps where the agent is planning, waiting on a network call, or idle between actions are removed. What remains are only the windows where real interaction happened, played back at normal speed. This makes recordings significantly shorter than the raw capture duration.
• Action overlays. Each interaction is burned into the video as overlay pills. Keyboard shortcuts (such as Ctrl+C, Return, or Escape) appear as labels on the frame where they were pressed — so non-visible keys like modifier chords show up clearly. Text typing is labeled “typing…” to avoid leaking sensitive input. Scroll events show a directional label.
• Click ripples and drag trails. Pointer events (mouse clicks, drags, and moves) are captured with their coordinates and burned into the video as click ripples and movement trails, so cursor activity is visible even when the cursor itself is small on screen.
• Sandbox-only capture. The recording is taken from inside the isolated sandbox environment. It never captures your local desktop, terminal, credentials, or anything outside the sandbox.

Note

Post-processing is best-effort: if the cut or overlay burn-in step fails for any reason, the original capture is uploaded without annotations. You still get a video — just without the smart cut or overlay pills.

Example recordings

UI change evidence

An agent validates a visual change, records the before-and-after behavior, and attaches the recording to the pull request for the reviewer.

Example prompt:

Add a new feature to tab groups where new tab groups get a random color by default
that is different from already-used colors. This should be disabled by default and
exposed as a setting users can toggle on. Test these changes thoroughly.

A public-facing example video for this use case is pending.

End-to-end QA of an existing flow

An agent walks through a critical user journey — for example, Warp’s first-time onboarding flow — and records the complete interaction.

Example prompt:

Start a fresh Warp installation in the sandbox. Walk through the onboarding flow
from the welcome screen through to the first terminal session, interacting with
each step naturally. Record the entire session.

This gives you a reproducible, time-stamped clip of the flow that can be archived, diffed across releases, or shared with the team as a baseline.

A public-facing example video for this use case is pending.

Reproducing a bug

An agent follows the exact steps from a bug report and records them, producing a shareable reproduction artifact.

Example prompt:

Reproduce GitHub issue #13480: [describe the steps from the report]. Record the
session so the recording can be attached to the issue as reproduction proof.

For example, warpdotdev/warp#13480 was reproduced with Computer Use. Bug reproductions are one of the strongest use cases because the video is unambiguous — the recording either shows the bug or it doesn’t.

Troubleshooting

Recording was cut short

Each recording has a server-configured maximum duration of 10 minutes and a maximum file size of 1 GiB. When either limit is hit, the capture is stopped and finalized automatically.

If the conversation is cancelled while a recording is active, the recording is discarded rather than uploaded.

Retry guidance

Most recording failures are transient. If a recording fails or produces an unexpected result:

1. Check the agent’s output for the specific error message.
2. Retry the run; recording substrate errors typically clear on the next attempt.
3. If the failure repeats consistently across multiple runs, file an issue on the open-source Warp client repository with the error message.

Related

• Computer Use — enable Computer Use, understand security considerations, and configure models for Computer Use sessions.
• Viewing cloud agent runs — open and inspect cloud agent run transcripts in Warp or the browser.
• Security considerations — understand the sandboxed environment and data isolation model.
• Privacy — Warp’s data handling policies, including how run artifacts are stored.