Add --headful flag to wrangler dev for browser rendering

[ruifigueira]

Fixes BRAPI-1010

Add --headful flag to wrangler dev to launch Chrome in headful (visible) mode when using the Browser Rendering API locally. This is useful for debugging browser automation scripts during development.

---

• Tests
  • Tests included/updated
  • Automated tests not possible - manual testing has been completed as follows:
  • Additional testing not necessary because:
• Public documentation
  • Cloudflare docs PR(s):
  • Documentation not necessary because:

A picture of a cute animal (not mandatory, but encouraged)

[changeset-bot]

🦋 Changeset detected

Latest commit: 82b08a0

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

✅ All changesets look good

[ask-bonk]

I'm Bonk, and I've done a quick review of your PR.

This PR adds a --headful flag to wrangler dev that propagates through the config pipeline to make Miniflare launch Chrome in visible (non-headless) mode for browser rendering.

Issues (ranked by severity):

1. Missing --headful --remote validation — The --headful flag only affects local browser launching. If a user passes wrangler dev --headful --remote, the flag is silently ignored. The existing pattern in validateArgs (line 274) validates this for --live-reload and throws a helpful UserError. The same guard should be added for --headful. See suggestion on dev.ts below.

2. No tests added — The PR template checks "Tests included/updated" but no test files were modified. At minimum, the headful schema acceptance should be tested (e.g. verifying BrowserRenderingSchema parses { headful: true } correctly), and the conditional Chrome args in launchBrowser should be covered.

---

Suggestion for issue 1 — In packages/wrangler/src/dev.ts, add the following validation in validateArgs after the liveReload check (after line 278):

if (args.headful && args.remote) {
  throw new UserError(
    "--headful is only supported in local mode. Please just use one of either --remote or --headful."
  );
}

[ask-bonk]

The --headful flag only takes effect in local mode. Consider also adding a validation guard in validateArgs (after the liveReload && remote check at line 274) to throw a UserError when --headful is combined with --remote, matching the pattern used for --live-reload:

if (args.headful && args.remote) {
  throw new UserError(
    "--headful is only supported in local mode. Please just use one of either --remote or --headful."
  );
}

[ask-bonk]

The review has been posted successfully on PR #13011. Here's a summary of what I found:

Two actionable issues identified:

1. Missing --headful --remote validation (higher severity) — The --headful flag only affects local Chrome launching in Miniflare. If combined with --remote, it is silently ignored. I suggested adding a validation guard in validateArgs matching the existing --live-reload pattern, with a concrete code suggestion posted as an inline comment on dev.ts.

2. No tests added — The PR checks "Tests included/updated" but no test files were modified. The headful schema validation and the conditional Chrome args logic in launchBrowser should have test coverage.

The rest of the implementation (data flow through 9 files, changeset format, types, schema) looks correct and well-structured.

github run