OpenCode lets developers choose models, configure specialized agents, control tool permissions, and run multiple sessions. That flexibility creates an interesting browser question: can the same real-web task work reliably when the model changes, or is the workflow secretly dependent on one conversation and one lucky browser state? OpenCode browser automation with the BrowserAct Agent Skill separates the browser execution layer from the model. OpenCode decides what needs to happen; BrowserAct pro

Why model flexibility needs a fixed execution layer

OpenCode can work with many model providers. That makes it useful for routing: a fast model can handle routine extraction, while a stronger model investigates ambiguous pages or repairs a failed workflow.

But model comparison becomes meaningless if the browser conditions change between runs. Model A might inherit a logged-in session and loaded page. Model B might receive a fresh browser, a different region, or a CAPTCHA. The final reports look comparable while the tasks were not.

BrowserAct makes the execution variables explicit:

• browser mode and identity;
• cookies and authorized login state;
• session name and owner;
• fingerprint and proxy conditions where applicable;
• starting URL and page state;
• action and retry limits;
• screenshots and other artifacts.

OpenCode then becomes the orchestration and reasoning layer. The BrowserAct runtime remains the controlled test environment. For the surrounding architecture, read Why AI Agents Need a Browser Execution Layer.

Define the three-task challenge

Use tasks that exercise different browser requirements:

Task A: protected-page extraction

Retrieve a public but protected product page and return title, current price, availability, source URL, and retrieval time.

Task B: interactive public workflow

Open a documentation site, use its search or filters, find three matching release notes, and capture the selected state plus source links.

Task C: authorized logged-in inspection

Reuse a designated local browser identity, open an account dashboard, read a plan limit, capture evidence, and perform no write action.

The shared output contract is:

{
  "task_id": "task-a",
  "verdict": "pass|fail|blocked",
  "session": "opencode-task-a",
  "browser_identity": "public-stealth",
  "started_at": "ISO-8601",
  "completed_at": "ISO-8601",
  "checks": [],
  "source_urls": [],
  "artifacts": [],
  "retries": 0,
  "human_interventions": 0,
  "failure_class": null
}

This structure prevents the model from hiding an incomplete run inside a polished summary.

Pro Tip: Give every task a maximum step count and retry budget. Without a budget, a stronger model may look “more reliable” simply because it spends far longer retrying.

First gate: install BrowserAct as a portable OpenCode Skill

OpenCode searches several Skill locations:

• .opencode/skills//SKILL.md for a project-native Skill;
• ~/.config/opencode/skills//SKILL.md for a global Skill;
• .claude/skills/ and ~/.claude/skills/ for Claude-compatible Skills;
• .agents/skills/ and ~/.agents/skills/ for cross-agent Skills.

OpenCode's official Agent Skills page documents portable Skill locations and permissions.

For portability, .agents/skills/ is a useful project-level choice. For personal use across unrelated repositories, a global path may be more convenient. Review the Skill source before allowing it to execute shell commands.

Use the official BrowserAct instruction:

Install browser-act. Skill source:
https://github.com/browser-act/skills/tree/main/browser-act
Verify it works after installation.

Then ask OpenCode to list the Skill and read the available BrowserAct environment state. The verification should not create a browser, import a profile, change proxy settings, or delete anything without approval.

Second gate: configure OpenCode permissions deliberately

OpenCode permissions can allow, deny, or ask before tools and actions. A browser workflow commonly needs four distinct permissions:

1. Load the BrowserAct Skill.
2. Run the BrowserAct CLI through shell access.
3. Read and write task artifacts inside the workspace.
4. Access an external browser profile or another path when explicitly required.

Do not replace these boundaries with blanket auto-approval. A conceptual baseline is:

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "skill": {
      "browser-act": "allow",
      "*": "ask"
    },
    "bash": "ask",
    "external_directory": "ask",
    "edit": "ask"
  }
}

The exact command patterns should be tightened after a hands-on run reveals what the Skill needs. Keep destructive browser operations and sensitive identity changes behind explicit confirmation even if routine read-only commands become approved.

OpenCode's permission system controls agent tools. The BrowserAct Skill also applies confirmation gates to sensitive browser creation, deletion, profile import, proxy, and security settings. Both layers matter: one protects the agent environment, the other protects browser identity and execution state.

Third gate: create one execution lane per task

Concurrency fails when multiple agents share an unnamed browser and all assume it belongs to them. Avoid “use the current tab.” Give each task ownership.

1. claims its session;
2. confirms the expected browser identity;
3. executes only its task contract;
4. writes only its result and artifact directory;
5. releases ownership when finished.

The coordinator waits for all three result files, validates their schemas, and produces the summary. It should not ask Task A to “quickly check” Task B's browser. That is how state contamination begins.

The detailed isolation pattern is covered in Concurrent Browser Automation.

Fourth gate: route each task to the correct BrowserAct capability

The three tasks should not use the same method.

Route Task A through extraction first

Try protected-page extraction before launching a full browser. If the required fields are present with their source context, stop. If the page requires interaction or the returned content is incomplete, escalate and record the reason.

Route Task B through an isolated browser

The selected filters are part of the evidence. Capture the current URL, filter values, visible results, and screenshots. If the site changes, the agent can reason over indexed page state rather than relying only on a brittle saved selector.

Route Task C through an authorized identity

Reuse only the named read-only account identity. If authentication has expired, return blocked_auth and use a human handoff. Do not copy credentials into the prompt or switch to another account to finish the benchmark.

For the extraction/browser boundary, use Web Scraping vs Browser Automation for AI Agents. For login boundaries, use AI Agent Login and Browser Safety.

Need isolated sessions without opening a pile of unmanaged windows? Try BrowserAct and give every OpenCode task an explicit browser lane.

Fifth gate: compare two models fairly

Run the same three-task suite with Model A and Model B. Reset only the variables that the benchmark defines.

Keep constant:

• BrowserAct version;
• task contracts and schemas;
• starting browser identities;
• login state policy;
• region and proxy policy;
• step and retry budgets;
• approval rules;
• artifact requirements;
• target pages and collection window.

Record per task:

Pro Tip: Compare P50 and P90 duration only for completed tasks, then report failures separately. Averaging timeouts and successes into one number hides both reliability and user experience.

Sixth gate: recover without crossing session boundaries

Each failure class gets its own response:

missing field
  → reinspect current page state
stale or empty content
  → reload once, then escalate retrieval method
interaction mismatch
  → refresh indexed state before another action
authentication expired
  → pause Task C and request human handoff
CAPTCHA or verification
  → use approved solve/handoff path
session ownership conflict
  → stop; do not take over another task's session
retry budget exhausted
  → return BLOCKED with artifacts and failure class

The benchmark should reward correct blocking. An agent that stops at an identity conflict is more reliable than one that hijacks another session and happens to return a value.

For human recovery, see Remote Assist Browser Automation.

Turn the suite into a reusable OpenCode Agent

Once the three tasks pass, create an OpenCode agent focused on browser evaluation. Give it the BrowserAct Skill, read access, limited artifact writes, and approval-based shell/browser actions.

A project structure can look like:

.opencode/
├── agents/
│   └── browser-benchmark.md
└── skills/
    └── real-web-benchmark/
        ├── SKILL.md
        ├── tasks/
        │   ├── protected-page.md
        │   ├── interactive-search.md
        │   └── logged-in-read.md
        ├── result.schema.json
        └── scorecard.md

Keep the reusable task suite separate from the BrowserAct Skill. BrowserAct describes how to operate the execution layer. The benchmark Skill describes what to test, what evidence counts, and how to score the result.

If one task becomes a recurring website-specific scraper, package that workflow using Create a Browser Automation Skill rather than making the benchmark agent rediscover it each run.

Rerun from a clean session

Start a fresh OpenCode session and provide a short instruction:

Run the real-web benchmark with Model A and Model B.
Use the locked BrowserAct environment and standard retry budget.
Do not perform write actions on target websites.
Return the scorecard and artifact paths.

The rerun succeeds when the agent discovers the right Skills, assigns unique sessions, preserves identity boundaries, produces valid result files, and returns a comparison grounded in artifacts.

Use the browser-agent reliability metrics to extend the scorecard as the suite grows.