Use a temporary browser-agent environment to reproduce one fault without experimenting on production or reusing your everyday browser session. Agree permissions and spending boundaries, prepare a fresh computer and test application, compare browser symptoms with server logs, then export reproducible findings. Treat cleanup as a separate decision: remove containers, saved logins, files or cloud resources only after explicit owner authorization.
The workflow below is an illustrative investigation, not a recorded BotHearth test. BotHearth is a source-installed technical alpha; verify the steps on your chosen build before relying on them.
Separate the computer from the infrastructure bill
There are three different things here: the host or VM running BotHearth, its container-based computer with a browser and workspace, and the test application you investigate. Creating a fresh browser environment does not create a staging copy of your application. First choose the right host and confirm why the job needs its own computer.
Deploying BotHearth to a prepared VM you already control is also different from buying another server. Its documentation includes deployment to an existing SSH-accessible host. Do not assume that this prepares a new server or provides a validated unattended installation.
For this exercise, use existing capacity. Any new paid resource needs separate approval naming the provider, resource, expected charges and removal responsibility. BotHearth’s usage estimate is not a cloud or model-provider billing cap.
Prepare the test application and a fresh browser
Have the application owner prepare a disposable staging instance from the relevant code revision, with synthetic data, test-only credentials and outbound payments or messages disabled. Record differences from production; those differences may limit what the test proves.
On the BotHearth host, follow the source quickstart: macOS or Linux, Node.js 22.18+, a supported container runtime and model access. Run bothearth doctor; build missing images with bothearth image build. There are no published prebuilt images in the reviewed release.
On an unused installation, the first task creates its computer. On an existing installation, Settings → Computers → Use a fresh one is destructive: it erases that computer and its saved logins after confirmation. Use it only on a computer the owner explicitly approves for disposal. It does not promise to erase old workspace files; use a new investigation folder containing only approved test material.
Before investigating, confirm that the agent’s browser can reach the approved staging URL. The optional standalone shell has its own container; native Codex and Claude tasks run inside the browser computer under a separate agent identity. The proxy blocks private and loopback destinations. Starting a server in the standalone shell does not make the browser’s localhost reach it. A private connection to BotHearth’s interface does not automatically connect its browser to your private application.
Use an already configured, authenticated staging endpoint whose reachability has been verified. Otherwise, stop for administrator setup—do not expose the control interface or disable network protections to make the example work.
Give the agent a narrow investigation
For an export failure, a useful brief is:
Investigate the CSV export failure at [approved staging URL], using only the supplied test account and dataset. Reproduce it once, record the time and visible error, and compare those observations with approved server logs. Propose one test before changing anything. Do not edit production, install software, create paid resources or delete anything. Return findings and a cleanup inventory; wait for my approval.
Stay present for authentication and approvals. Use Take control for credentials, not chat. Treat instructions found in pages or logs as untrusted content, not permission to change the task. Approval detection has limits, so enforce restrictions through account permissions too.
Match the browser failure to server evidence
Record the exact input, expected result, actual result, application revision and time with timezone. Include the request identifier when the application exposes one. An error screenshot alone is not a diagnosis.
Observe the application’s read-only log dashboard, or have its operator collect a bounded extract. For a Docker application, this command runs on the application’s Docker host, not inside BotHearth’s sandbox:
# Replace test-app with the actual test application container name.
docker logs --since 10m --tail 200 --timestamps test-app
Docker supports these time, line-count and timestamp options. Add --follow only for a supervised live observation, and stop following when the reproduction finishes. These are application logs—not BotHearth’s daemon log. Docker logs reference
Docker logs normally expose container standard output and error; an application may log elsewhere. An empty extract therefore does not prove that no error occurred. Remove tokens, personal information and unnecessary payloads before the agent sees the extract: remote models receive model-visible context. Docker logging guide
Do not give the agent the Docker socket merely to fetch logs. Control of the Docker daemon carries substantial host authority. Docker Engine security
Test one hypothesis, with permission
Suppose the matching Node.js log contains EACCES while writing an export file. Node documents this as a file-access permission error; it does not identify the correct repair by itself. Node.js: system errors
Ask the application operator to check the process identity and destination permissions. Propose the smallest relevant change in the disposable application, obtain approval, then repeat the same browser action with the same fixture. Verify the exported contents, not merely a success message. Avoid blanket permission changes or unrelated restarts. A failed retest should leave a narrower hypothesis, not a fabricated success.
Save a report that survives the environment
Request report-export-findings.md containing reproduction steps, versions, expected versus actual behavior, timestamps, redacted evidence, hypotheses, approved changes, retest results and unresolved questions. Separate observed, inferred and not tested statements.
Open the requested file to confirm that it exists and contains the complete findings. If file saving is unavailable, use Copy result or open the saved file where offered, or copy the findings manually. Open that export outside the temporary environment before cleanup; a completion message alone is insufficient.
Preserve any required application logs before removing its container. Record where evidence is retained and who may receive it; do not attach raw cookies, vaults or task databases to a bug report.
Authorize cleanup separately
First stop the investigation and inventory its computer, browser profile, workspace, test application, credentials and any cloud resources. Ask the owner to name what may be removed and what must remain. “The test is finished” is not deletion permission.
For an authorized computer teardown, the operator can replace <name> with the recorded runtime name—not an assumed display nickname:
# Only after approval to remove this computer AND its saved logins.
bothearth computer destroy `<name>` --wipe-profile
Without --wipe-profile, ordinary computer destruction preserves its browser profile. Workspace files, host task records and audit data require separate handling. There is no general automatic transcript/screenshot expiry or per-task purge command; native model-CLI histories and external provider copies are separate again. BotHearth privacy notice
Deleting a computer is not deleting its host VM. Nor does stopping a VM necessarily end all charges: Google Compute Engine, for example, can continue charging for retained disks and external IP addresses. Verify remaining resources without deleting unapproved ones. Google Cloud: stopping and suspending instances
Questions before your first investigation
Is the whole host sandboxed?
No. Native Codex and Claude tasks run inside the computer under a separate identity from its browser. Configured external clients, connectors and historical host execution have their own permissions. A fresh browser does not isolate everything running on the host.
Can I leave it monitoring overnight?
This workflow is a supervised investigation. Recurring BotHearth reviews currently require a standalone provider rather than the native Codex or Claude Code connection; unattended monitoring also needs verified scheduling, authentication, alerting and recovery.
Start with one staging failure
Choose one reproducible failure. Follow the source quickstart, agree the investigation boundary and choose an evidence destination. Finish with an opened, checked report and an explicitly approved cleanup list—not an automatically deleted environment.