[Browser Run] Document session guardrails

[meddulla]

Summary

Document session guardrails for Browser Run

Documentation checklist

• [X ] Is there a changelog entry (guidelines)? If you don't add one for something awesome and new (however small) — how will our customers find out? Changelogs are automatically posted to RSS feeds, the Discord, and X.
• [X ] The change adheres to the documentation style guide.

[cloudflare-docs-bot]

Review

⚠️ 1 warning, 💡 1 suggestion found in commit 710be97.

👉 Fix in your agent 👈

Fix the following review findings in PR #32876 (https://github.com/cloudflare/cloudflare-docs/pull/32876).

Before making changes, review each finding and present a brief summary table:
- For each finding, state whether you agree, disagree, or need clarification
- If you disagree (e.g. the fix requires disproportionate effort for minimal benefit,
  or the finding is factually incorrect), explain why
- If you need clarification before deciding, ask those questions
- Then share your plan for which issues to tackle and in what order

After triaging, follow this order:
1. Post a comment on this PR for any findings you are skipping, with the finding ID and your reasoning.
2. Then commit the fixes for the legitimate findings.

The comment must come before the commit — the bot reads PR comments when a new
push triggers a review, so skip comments posted after the push will be missed.

---

## Code Review

### Warnings (1)

#### CR-4d3413f8ce1b · API conflation: session guardrails vs. Live View readonly
- **File:** `src/content/changelog/browser-run/2026-08-20-guardrails.mdx` line 24
- **Issue:** The post defines guardrails as a per-session, immutable host allowlist, then tells readers to 'Set `guardrails` when generating a link' for a view-only Live View URL. But the existing Live View docs use `guardrails: { mode: 'readonly' }` only to restrict interactivity; that parameter does not accept `allowedDomains` or `allowedDomainSets`. This contradicts the earlier claim that guardrails cannot be changed after session acquisition.
- **Fix:** Clarify that the session's host-allowlist guardrails automatically apply to anything the session does, including a Live View stream. If you want to mention view-only sharing, describe it as a separate `guardrails: { mode: 'readonly' }` option on the Live View link, not as setting the same guardrails object again.

### Suggestions (1)

#### CR-f14326dcfe2c · Frontmatter conflates two features
- **File:** `src/content/changelog/browser-run/2026-08-20-guardrails.mdx` line 3
- **Issue:** The `description` says guardrails let you 'restrict which hosts a browser session can reach and share read-only views of a running session.' Sharing a read-only view is a Live View feature controlled by `guardrails: { mode: 'readonly' }`, not the new host-restriction guardrails.
- **Fix:** Keep the description focused on the host-allowlist capability only, and address read-only Live View separately in the body if needed.

Code Review

This code review is in beta and may not always be helpful — use your judgment.

Warnings (1)

File

Issue

changelog/browser-run/2026-08-20-guardrails.mdx line 24

API conflation: session guardrails vs. Live View readonly — The post defines guardrails as a per-session, immutable host allowlist, then tells readers to 'Set guardrails when generating a link' for a view-only Live View URL. But the existing Live View docs use guardrails: { mode: 'readonly' } only to restrict interactivity; that parameter does not accept allowedDomains or allowedDomainSets. This contradicts the earlier claim that guardrails cannot be changed after session acquisition. Fix: Clarify that the session's host-allowlist guardrails automatically apply to anything the session does, including a Live View stream. If you want to mention view-only sharing, describe it as a separate guardrails: { mode: 'readonly' } option on the Live View link, not as setting the same guardrails object again.

Suggestions (1)

File

Issue

changelog/browser-run/2026-08-20-guardrails.mdx line 3

Frontmatter conflates two features — The description says guardrails let you 'restrict which hosts a browser session can reach and share read-only views of a running session.' Sharing a read-only view is a Live View feature controlled by guardrails: { mode: 'readonly' }, not the new host-restriction guardrails. Fix: Keep the description focused on the host-allowlist capability only, and address read-only Live View separately in the body if needed.

Conventions

_{No convention issues found.}

Style Guide Review

_{No style-guide issues found.}

Commands

Only codeowners can run commands. Post a comment with the command to trigger it.

Command	Description
/review	Runs a review now. Incremental if a prior review exists, full if not.
/full-review	Re-reviews the entire PR diff from scratch, ignoring incremental history. Useful after a rebase, when you want a fresh review, or if the bot gets out of sync and reports issues that no longer exist.
/ignore-review-limit	Permanently lifts the 2-review automatic limit for this PR. Future pushes will trigger reviews as normal.
/disable-auto-review	Stops automatic reviews from triggering on future pushes to this PR. Codeowners can still run /review or /full-review manually.
/rebase	Rebases the PR branch against production. On conflict, attempts to resolve automatically using AI. Stops with an explanation if confidence is not high enough.

[simonabadoiu]

Missing a "Verify guardrails are working" mini-section (make a request to a blocked host, expect 403 with the two headers) would help self-service debugging. Maybe?