arc-browser-ops

Arc Browser Ops

General-purpose browser automation skill. Attaches Playwright MCP to the user's already-running Arc browser via Chrome DevTools Protocol (CDP), reusing the user's existing logged-in sessions. Works for any web task: form filling, multi-page flows, data extraction, dashboard navigation, posting content, toggling settings, etc.

Why this works

Arc is Chromium-based, so it exposes CDP when launched with a debug port. Playwright cannot launch Arc itself, but it can attach to an already-running Arc instance via connectOverCDP and inherit the user's existing profile — cookies, MFA tokens, logins, all of it. This skill wraps that pattern through the Playwright MCP server so you can drive Arc directly from this conversation.

When to use

Activate when the user asks for any of:

• "Fill out this form / survey / application at "
• "Do on " (e.g. "post this to X", "update my Notion page")
• "Resume / continue the " from a prior session
• "Extract / scrape / read from "
• "Click through on "

Do not use for: tasks that don't require auth or interactivity (use curl or a fetch tool), or tasks fully covered by a dedicated MCP (Gmail, Linear, Notion, GitHub, etc. — prefer those direct integrations).

Hard prerequisites

1. Arc launched with CDP:

   open -a "Arc" --args --remote-debugging-port=9222
   

   (Alternative if open -a doesn't take the flag through reliably: /Applications/Arc.app/Contents/MacOS/Arc --remote-debugging-port=9222)
   • Verify: curl -s http://localhost:9222/json/version returns JSON.
   • If it fails, ask the user to quit Arc completely (⌘Q, check menu bar too) and relaunch with the flag. See [[project-playwright-mcp]] memory.
2. The target site is already open and logged in in an Arc tab. Do not call browser_navigate to open a logged-in URL from scratch — through Playwright MCP this opens in a fresh context that does not inherit Arc's cookies, even though Arc itself is connected. Result: the page redirects to a login or /sorry.aspx-style error.
   • Raw Playwright SDK can pick up browser.contexts()[0] to reuse the default context, but the MCP wrapper does not expose that — switch to the user's existing tab instead.

Operating principles

0. Return focus to the caller's app when done

Browser automation pulls Arc to the foreground, which buries whatever app the user was working in (Cursor / Claude app / Terminal / VS Code). Before touching the browser, snapshot the frontmost app; when the skill completes (success or failure), restore it.

# At the very start of browser work
bash lib/macos/return-focus.sh save

# ... do all browser ops ...

# At the very end (success path AND failure path)
bash lib/macos/return-focus.sh restore

Always pair save with restore — both in the happy path and in any early-exit branches (errors, user cancel, refused operations). Treat it like a defer / finally block.

Opt-out: set WOVOL_LAB_NO_RETURN_FOCUS=1 in the environment when the user explicitly wants the browser to stay in front (e.g. they're following along visually). The helper becomes a no-op in that case.

1. Don't ask the user a wall of questions

This is the #1 feedback. Default workflow:

1. Read context first: check MEMORY.md and any linked memory files for user profile (name, status, nationality, language, role). The project-level CLAUDE.local.md (gitignored) is the canonical place for per-user defaults the skill should use.
2. Snapshot the page, identify all fields and required values.
3. Best-effort fill the entire form using inferences from context and sensible defaults — do not stop to ask per-field.
4. Show a single summary of every field you filled (and which ones you skipped/left blank), then ask one question along the lines of: "OK to proceed? Reply with edits if anything needs fixing." Accept either "OK / proceed / yes" or a list of edits in one response. (Match the user's preferred language — see CLAUDE.local.md.)
5. Apply edits if any, then proceed to the next step (usually a confirm / submit button).

Only ask up-front when:

• A field requires information not derivable from context or the page itself (e.g. a specific custom essay, a phone number that isn't in memory, a university name when the user is not actually in university).
• An action is irreversible and high-stakes (final submit, payment, posting publicly). For those, confirm before clicking.

Never paste passwords or secrets into chat — route through the visible browser. See [[feedback-passwords]].

2. Use the right tab — don't open new ones

Before any action:

1. List CDP targets to find the relevant tab:

   curl -s http://localhost:9222/json | python3 -c "import sys,json; [print(i,t.get('url','')[:90]) for i,t in enumerate(json.load(sys.stdin)) if t.get('type')=='page']"
   

2. Or use mcp__plugin_everything-claude-code_playwright__browser_tabs with action=list. Note: this can occasionally timeout on the first call against Arc CDP — retry once, or fall back to the curl approach above.
3. Switch to the target tab with browser_tabs action=select, index=N.

browser_navigate is only safe for public / unauthenticated URLs.

3. Be fast — many sites have short session TTLs

Snapshot → fill → confirm → submit should happen in one tight sequence. Don't pause for unnecessary back-and-forth between snapshot and submit — some forms (e.g. recruitment / banking sessions) expire in minutes and redirect to /error.aspx or similar. If that happens, the form data is lost and the user must re-login and reopen the page.

If a fresh snapshot is needed (e.g. after a step changes the page), grab it immediately before the next action — don't reuse stale element refs.

4. Never auto-submit irreversible actions

Stop and ask before:

• Final survey/application submit button
• Sending a message, post, or comment publicly
• Confirming a purchase, payment, or subscription change
• Deleting, deactivating, or closing an account
• Any "Confirm" button that leaves the form un-editable afterward

Doesn't need confirmation:

• Navigating between pages
• Filling fields (still reversible until submit)
• Clicking "Next" or equivalent (e.g. 確認画面へ on Japanese sites) to advance to a review page (the user can still cancel from the review screen)
• Reading / extracting data

5. Use fill_form for batch field entry

mcp__plugin_everything-claude-code_playwright__browser_fill_form accepts an array of fields (combobox / radio / checkbox / textbox) in one call. Prefer this over per-field clicks — faster, fewer round trips, and the radio/combobox values can be addressed by their visible label.

Standard playbook

1. Verify CDP up:           curl -s http://localhost:9222/json/version
2. Find the right tab:      browser_tabs list  (or curl /json)
3. Switch:                  browser_tabs select index=N
4. Snapshot:                browser_snapshot
5. Plan fills from context: read user memory, infer values, pick defaults
6. Batch fill:              browser_fill_form
7. Summarize + confirm:     one question, list every filled value + skipped
8. Apply edits if any:      browser_fill_form again
9. Advance:                 browser_click on Next (or local equivalent)
10. If review screen:       summarize what will submit, let user do the
                            final click themselves (or get explicit go-ahead)

Failure modes & recovery

Symptom	Cause	Fix
curl localhost:9222 fails	Arc not launched with CDP	Ask user to ⌘Q Arc completely, relaunch with open -a "Arc" --args --remote-debugging-port=9222
Page redirects to /sorry.aspx or login	browser_navigate opened fresh context without Arc cookies	Use browser_tabs select on the existing logged-in tab instead
Form refs are gone / wrong / "element not found"	Page reloaded, stale snapshot	Take a fresh browser_snapshot before next action
browser_tabs list timeout	Playwright MCP + Arc CDP quirk on first call	Retry once, or use curl /json to enumerate targets
/error.aspx, "session expired", or localized equivalent	Form sat too long between open and submit	User re-logs in, reopens form tab, then re-run the playbook — quickly
Selectors keep failing on a SPA	Dynamic content not yet rendered	browser_wait_for on a visible text, or re-snapshot after a short pause

Memory hooks

This skill should consult and update the following memory:

• [[user-role]] — name, status, nationality, language, role
• [[project-playwright-mcp]] — Arc CDP launch requirement
• [[feedback-passwords]] — never accept secrets in chat
• Task-specific project memories (e.g. [[project-survey-lycorp]]) — for multi-session continuations, record exactly what was filled and any domain-specific gotchas (session TTL, eligibility quirks, etc.).

When a new web task is in progress and may span sessions, save a project_<site>_<task>.md memory so a future session can resume cleanly.