cli: add custom chrome policy flags to browser and pool commands

[rgarcia]

Summary

Adds CLI support for setting a custom Chrome enterprise policy (the API's chrome_policy field, already supported by the Go SDK) on three commands:

• kernel browsers create
• kernel browser-pools create
• kernel browser-pools update

Each gains two mutually-exclusive flags:

• --chrome-policy '<json>' — an inline JSON object
• --chrome-policy-file <path> — read the object from a file (- reads stdin)

This mirrors the existing --payload / --payload-file and --data / --data-file conventions.

kernel browsers create --chrome-policy '{"BookmarkBarEnabled": false}'
kernel browsers create --chrome-policy-file policy.json
cat policy.json | kernel browser-pools update my-pool --chrome-policy-file -

Design notes

• A shared parseChromePolicy helper parses into map[string]any, so non-object JSON (arrays, scalars, null) is rejected with a clear error before any request is sent.
• chrome_policy uses omitzero, which only drops a nil map — a non-nil empty {} would serialize as "chrome_policy":{}. Assignment is therefore guarded by len > 0, so an empty object is treated as "unset".
• On browser-pools update, an empty {} cannot clear an existing policy (omitzero strips it before it reaches the server). Rather than silently no-op, this surfaces a warning in human output (suppressed under -o json to keep stdout valid).
• Kernel-managed policies (extensions, proxy, automation) are enforced server-side. The CLI forwards the object verbatim and surfaces the API's error, rather than duplicating a blocklist that would drift.

Scope

• browsers update and invoke are intentionally excluded: their SDK params structs (BrowserUpdateParams, InvocationNewParams) carry no chrome_policy field, so there's nothing to wire until the SDK is regenerated.
• The policy echoes back via --output json with no printer changes (response structs already carry the field).

Test plan

• Unit tests for all three commands: inline policy applied, empty {} omitted (asserted at both the Go field and the serialized JSON), invalid JSON / null rejected, parser covers file + stdin + whitespace + missing-file, and the pool-lease conflict contract is locked (--chrome-policy stays out of the allowed-flag set).
• make test (go vet + go test ./...) passes; gofmt clean.
• E2E against a live environment via the built binary: inline/file/stdin create echo the policy; pool create + get persist it; pool update replaces it and an empty {} no-ops without clearing; invalid/null/mutual-exclusion exit non-zero before any API call; and the server correctly rejects ProxyMode / ExtensionInstallForcelist with the CLI surfacing the error.

Note (pre-existing, unrelated)

When a browser-config flag is combined with --pool-id/--pool-name, the existing conflict-confirmation prompt (pterm.DefaultInteractiveConfirm) does not treat EOF / non-TTY stdin as "no", so it blocks in a non-interactive pipeline. This predates this change and affects all config flags equally; flagging it as a possible follow-up.

🤖 Generated with Claude Code

---

Note

Low Risk
CLI-only feature forwarding JSON to existing API fields; validation is local and server enforces blocked policies. No auth or data-path changes.

Overview
Adds --chrome-policy and --chrome-policy-file (mutually exclusive, - for stdin) to kernel browsers create and kernel browser-pools create / update, wiring the API’s chrome_policy field through a shared parseChromePolicy helper.

Policies are only sent when the parsed object is non-empty (len > 0), so {} is not serialized on create. On pool update, passing {} does not clear an existing policy; the CLI warns in human output and stays silent with -o json. poolLeaseAllowedFlags is extracted so --chrome-policy is not treated as allowed alongside --pool-id/--pool-name, surfacing the existing pool-lease conflict warning instead of ignoring the flag.

README documents flags, examples, and the pool-update clearing limitation. Unit tests cover parsing, SDK params, JSON omission, warnings, and pool-lease behavior.

^{Reviewed by Cursor Bugbot for commit 6a470a3. Bugbot is set up for automated code reviews on this repo. Configure here.}

[masnwilliams]

lgtm

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: Whitespace policy triggers false update warning
  • The warning now only appears for an explicit empty JSON object by checking for a non-nil parsed policy map, and a regression test confirms whitespace-only input stays quiet.

Or push these changes by commenting:

@cursor push 901ffb4d16

_{You can send follow-ups to the cloud agent here.}

^{Reviewed by Cursor Bugbot for commit 6a470a3. Configure here.}

[cursor]

Whitespace policy triggers false update warning

Low Severity

On browser-pools update, the empty-policy warning keys off whether --chrome-policy or --chrome-policy-file was provided, not whether parsing produced an explicit {} object. Whitespace-only inline values, an empty policy file, or stdin with only blanks return nil from parseChromePolicy but still print that an empty policy will not clear the pool.

 

^{Reviewed by Cursor Bugbot for commit 6a470a3. Configure here.}