Editorial review pendingon version support under review
Action boundary
Before you act
- Expected result
- A fixture browser run captures a stable observation and blocks every destructive transition pending human confirmation.
- Failure mode
- Session leakage, brittle selectors, hidden state, or an automatic click turns a test flow into an unintended real-world action.
- Rollback
- Close the disposable profile, revoke its test credentials, discard session state, and disable the browser capability before changing selectors or policy.
A browser is stateful, ambiguous, and powerful
OpenClaw’s browser documentation covers profiles, local/remote control, and security considerations. That does not make every webpage a safe automation target. A browser carries session state; a page can change without notice; and a label that looks like “continue” may submit, purchase, publish, or reveal data.
Build a browser flow in three layers:
- Observe: open only the disposable target; read an accessibility/DOM signal or visible text; assert a known non-sensitive state.
- Propose: produce the intended next action with URL, target label, input values, and reason. Do not click or type sensitive data.
- Confirm: require a fresh human confirmation for a write, submission, account change, download, payment, or outbound message. Record the operator, timestamp, and final target before acting.
Use stable, human-meaningful selectors where the test target provides them. Do not work around CAPTCHAs, authentication barriers, terms, or access controls. A test that requires bypass is a failed test.
Lab — a three-step fixture
Create a local or disposable page with: a public heading, a text field, and a “Submit test” button. Your dry run must assert the heading and show the proposed text input, but stop before clicking. Add a separate confirmation-only fixture that verifies the blocked status without invoking a browser.
Capture: fixture URL, non-sensitive session/profile name, selector/assertion, screenshot or text snapshot, proposed action, and blocked confirmation result. Do not capture personal cookies, tokens, or browsing history.
Checkpoint
A test browser reaches a button labelled “Publish.” What happens next?
A. Click it because the fixture is probably safe
B. Retry with a hidden selector
C. Return a proposal and require a fresh named confirmation
D. Copy the browser cookies into the tool log
Answer: C. The label indicates a potential irreversible action. The confirmation is part of the capability contract, not a user-interface inconvenience.
Supplementary orientation
The conditional Playwright video candidate is relevant only as a short orientation to structured browser control. Watch only after its human-review gate clears. This lesson’s source of truth is the pinned OpenClaw browser and policy documentation plus your own disposable fixture evidence.
Lesson checkpoint
Ready to move on?
Mark this lesson complete when you can apply its outcome without relying on the examples above.