Hermes Browser Use: a safe first-week checklist

This checklist is for a Hermes install that already runs. The goal for the week is one bounded browser task: open a public page, return a small table, and include the URL. Configuration details live in L12: Browser Use mode. This page is the order to follow so that lesson does not become a settings tour.

We re-checked the official Browser Automation docs on October 22, 2026. The older /browser-setup URL from the August lesson returned 404. Provider setup is on that same Browser Automation page. The Browser Use CLI repository is the upstream driver project.

If you are still deciding whether Hermes is the right harness, start at L01: Hermes Agent explained and install with L02 before any browser day.

Who this checklist is for

You already have Hermes. You want the browser for a real job, and you do not want the first run to be a logged-in account. Week one fits if you can name one public page and one fact on that page. It does not fit if the task requires a password, a payment, a delete, or a message. Those stay manual. L07: Security essentials is the longer version of that boundary.

Day 0: Boundaries before any browser

Write these down before you enable anything:

• Use a separate browser profile from the one you use for mail, banking, and admin.
• Keep passwords, recovery codes, and API keys out of the prompt and out of the saved transcript.
• A person approves anything that submits, pays, publishes, deletes, or sends.
• The first task is read-only. The success condition includes a URL.

Hermes can act with the session of the browser it controls. A signed-in window is your session. The default local browser in the October docs is a packaged Chromium, not your everyday Chrome. Stay on that clean browser until you have a reason to attach to another one.

Day 1: Verify Browser Use is actually on

Browser Use mode gives the agent one browser_exec tool. The agent writes a short Python program that can navigate, click, type, and extract in one run. On a current install, the docs say this mode is the default when browser.backend is unset. The engine ships with Hermes. browser_exec is offered only when the session also has terminal access. If the engine is missing, Hermes falls back to built-in browser tools.

Start a fresh session and run:

/browser status

Confirm the browser source and whether Browser Use mode is active. The full command and config reference is L12. Day 1 passes when status output matches the source you think you selected. A saved API key is not a selection. The docs say hermes tools writes the provider, and once a selection exists, adding a key does not switch it.

Day 2: One read-only public-page task

Use the official docs page as the fixture so you are not testing against your own product:

Open the official Hermes Browser Use documentation.
Return the names of the supported browser providers in a table.
Include the page URL. Do not sign in, download files, or submit forms.

Result	Verdict
Provider starts, the table matches the page, and the URL opens	Pass
The table looks right and the URL is missing	Fail
The agent signs in or downloads a file	Stop. Tighten the prompt and the profile before another run

Copy the URL into a browser you control and read the page. That human check is the proof, not the agent’s confidence.

Day 3: Pick a browser source deliberately

The driver and the browser are different choices. L12 keeps the full trade-off table. For week one, decide in this order:

Need this week	Start with	Leave for later
A clean public page	Packaged Chromium, the default local source	Your personal Chrome profile
A window you can watch	Local Chromium via /browser connect	Any profile that is already signed in
A remote run	Browser Use Cloud, Browserbase, Firecrawl, or Nous Subscription	Private URLs. The docs block private and loopback addresses unless you change that on purpose
Camofox	Built-in Hermes browser tools	Browser Use mode. Camofox has no CDP endpoint for this driver

Lightpanda is a local engine in the same docs. Treat vendor speed claims as a hypothesis. If the page is a normal public article, packaged Chromium is enough for the week.

The real-profile toggle (browser.use_real_profile) copies cookies so the agent can browse as you. Leave it off. It is a consent switch, not an isolation boundary.

Day 4: Named sessions for concurrent work

Current Hermes builds accept a session name:

browser_exec session=research
browser_exec session=admin

Each name gets its own daemon state and, on a cloud provider, its own cloud browser. That stops two tasks from clicking in the same tab. It does not make either task safe. Each session still inherits the profile, cookies, and provider you attached.

If you only have one task this week, skip named sessions. Use them when two runs would otherwise share a tab.

Day 5: Compare Browser Use with the built-in tools

Run the Day 2 task twice. Once with Browser Use available. Once after /browser use off or browser.backend: "off", then a fresh session. Record:

• whether the table matches the page;
• whether the URL was returned;
• how many retries you had to approve;
• whether a recording or log exists;
• the model and provider cost your setup shows.

Keep the mode that was more reliable on this page. A vendor comparison is not evidence for your sites. The side-by-side method is in L12.

Day 6: Agent Browser skill, or Hermes mode

Hermes local browsing is driven through the agent-browser CLI. That name collides with a catalog skill. They are not the same switch.

Tool	What it is	Week-one use
Hermes Browser Use mode	The in-product browser_exec driver. Default when the backend is unset	The path this checklist tests
Agent Browser	vercel-labs CLI skill. Catalog command: npx skills add vercel-labs/agent-browser --skill agent-browser	Install only if you want a reviewed procedure for that CLI. Lesson: tools L05
browser-use	A separate CDP skill. Catalog command: npx skills add browser-use/browser-use --skill browser-use	Not required to turn Hermes mode on
Browser Harness	Logged-in, self-healing browser project. No catalog install command	Leave it. The mode already describes browser-harness as its engine
Defuddle	Cleans a page to HTML or Markdown after you have a URL	Optional extract step, not a browser

If Day 2 already passed, you do not need a catalog skill to “finish” Browser Use. Add one only for a gap you can name. The wider keep list is the five-skill starter stack. The long map is the 17-item toolkit.

Installing Agent Browser does not flip browser.backend. If Hermes still shows built-in tools, check /browser status, terminal access, and the backend setting. That failure mode is also in L12’s troubleshooting table.

Day 7: What not to automate yet

Keep these on the human side of the desk:

• logins and second factors;
• payments, subscriptions, and plan changes;
• deletes, including mail and repository data;
• messages, posts, and comments;
• anything on a private URL you have not decided is in bounds.

Schedules and always-on delivery belong to L08: Automation, after this manual task has passed more than once. Skills you intend to keep belong to L04: Skills and skill bundles.

FAQ

Why did Camofox stay on the built-in tools?

The October 2026 docs say Camofox has no CDP endpoint for the Browser Use driver, so those setups keep the built-in tools. That is expected. It is not a failed install of the mode.

I added an API key. Why is the provider unchanged?

Keys supply credentials. The selected provider is the one written by hermes tools. A key alone does not switch a provider that is already selected. Never-configured setups can still autodetect. Read /browser status after you change the selection, in a new session.

The agent answered without a URL. Is the setup fine?

No. The Day 2 bar requires a URL you can open. A confident summary without that URL fails the task even if the backend is correct.

Do named sessions make a signed-in browser safe?

No. They separate concurrent work. They do not remove cookies, and they do not add an approval step.

A private URL was blocked. Should I turn that off?

Not as a week-one fix. The docs reject private and loopback addresses so a cloud browser does not become a path to your LAN. Decide whether that host and profile are in scope before you change the guard.

Next steps

Next	Use it for
L12: Browser Use mode	The config page this checklist assumes
Tools L05: Agent Browser skill	Install and review the catalog CLI skill
Five-skill starter stack	Research, extract, write, verify, review
L04: Skills and skill bundles	Saving a procedure you have already tested
Skills directory	The catalog behind the skill links above

Sources

• Hermes Browser Automation, checked October 22, 2026
• Browser Use
• L12: Set Up Hermes Browser Use Mode Safely
• Catalog commands for agent-browser, browser-use, browser-harness, and defuddle, checked October 22, 2026

Put this to work

Separate the driver, the browser source, and the catalog skills, then keep week one inside one public page.

Try

On a fresh Hermes session, run /browser status and extract the provider names from the official Browser Use docs, with the page URL and no sign-in.

Prove it worked

The provider starts, the URL opens, and the list matches the page. Record the backend you actually selected, not the API key you saved.

Keep in view

• Browser Use mode is the Hermes driver. A catalog browser skill does not turn it on.
• The October 2026 docs default the mode on when the backend is unset, and they offer it only to sessions with terminal access.
• A result without a source URL fails, even when the answer sounds right.

Learn the workflow: Hermes Browser Use mode →