Two fixes that fell out of testing PR #84 against a real account.
1) list_cloud_profiles was hitting /profiles?pageSize=200 and getting 422
back — the API caps pageSize at 100. Anyone with more than 10 profiles
already saw a silent truncation before this (the request returned 10
items by default) and anyone bumping past 100 would hit the hard error.
Now paginates with pageSize=100 until totalItems is reached. My account
is at 18 and climbs every sync_local_profile() call, so this was going
to bite shortly.
2) sync_local_profile only exposed profile_name + browser. profile-use
v1.0.4 shipped three more flags that solve real pain:
--cloud-profile-id <uuid> → update an existing cloud profile
--domain <d> → only these domains (repeatable)
--exclude-domain <d> → drop these domains (repeatable)
Wired up as cloud_profile_id / include_domains / exclude_domains kwargs.
When cloud_profile_id is passed, profile-use prints "♻️ Using existing
cloud profile" instead of "Profile created: <uuid>" — special-cased the
regex path to just return the caller-supplied UUID.
Also drops the "Upstream limitations" section from profile-sync.md (both
limitations are fixed as of v1.0.4) and adds two worked examples:
- refresh the same cloud profile (cloud_profile_id=)
- push only Stripe cookies into it (include_domains=["stripe.com"])
Verified end-to-end:
sync_local_profile("browser-use.com", include_domains=["stripe.com"])
→ "Domain filter: 43 → 1 cookies (include=[stripe.com])"
→ cloud profile cookieDomains == ["m.stripe.com"]
→ second call with cloud_profile_id=uuid printed "Using existing cloud
profile" and returned the same UUID (idempotent).
* remote: Python API for remote browsers, profiles, and local-profile sync
No CLI, no new entrypoint. Every helper is a Python function callable from
inside a normal `browser-harness <<'PY'` block. run.py pre-imports them.
admin.py:
- start_remote_daemon(name, profileName=None, **create_kwargs)
Now forwards every documented POST /browsers kwarg (profileId, profileName,
proxyCountryCode, timeout, customProxy, browserScreenWidth/Height, ...).
profileName is resolved client-side via list_cloud_profiles — no browser-use
API change needed. Prints liveUrl and auto-opens it locally when a GUI is
detected (macOS/Windows always; Linux needs $DISPLAY / $WAYLAND_DISPLAY);
headless servers print only.
- list_cloud_profiles() — GET /api/v3/profiles + per-profile detail; returns
[{id, name, cookieDomains, lastUsedAt, userId}]. Agents should report
len(cookieDomains) not the full list — profiles can have 500 cookies across
dozens of domains.
- list_local_profiles(), sync_local_profile(name) — shell out to `profile-use`.
sync_local_profile returns the newly-created cloud UUID.
Profile-sync skill rewritten Python-first with the chat-driven flow (ask the
user which profile; summarize by domain count, never dump cookies) and calls
out the two upstream limitations (sync always creates a new cloud profile; no
per-domain filtering) that need a PR to browser-use/profile-use — they can't
be fixed in browser-harness because the Browser Use API has no cookie
upload/download endpoint.
SKILL.md remote-browsers section updated to match, leading with the parallel
sub-agent use case.
* remote: fix misleading 'no GUI' message when webbrowser.open raises
cubic flagged this on #84: if _has_local_gui() is True but webbrowser.open
raises (e.g. no default browser configured), the code fell through to the
final 'no local GUI — share the liveUrl' line, which is wrong on both counts.
Restructure so each branch produces exactly one accurate message.
Magnus Müller