#Browser automation

I tested browser-use and camofox, none could work for posting in vbulletin-based forum. Any suggestion on what other approach I should try?

Yeah, for old vBulletin I’d try something less “agentic” and more deterministic.

My order would be:

1. Plain Playwright or Selenium

   • persistent profile/session
   • explicit waits
   • handle iframe/editor directly
   • sometimes vBulletin’s rich editor is the real problem, not the post button

2. Direct HTTP form submission, if allowed

   • inspect the network request when posting manually
   • replay the POST with cookies + hidden fields (securitytoken, thread/post ids, etc.)
   • for vBulletin, this is often way more reliable than UI automation

3. Real browser + CDP attach

   • log in manually once

• attach automation to your normal Chrome/Brave session
  • helps if anti-bot or weird legacy JS is involved

If I had to recommend one: use Playwright first, and if posting still fails, switch to replaying the actual POST request. Old forum software often behaves better with raw requests than with higher-level browser agents.

If you want, I can sketch the exact Playwright strategy for vBulletin posting, or the HTTP replay approach.

so for more modern ones, like for example, reddit? Or perhaps social media posts in general?

For modern sites, my recommendation changes a bit:

Best order:

1. Official API first
   Best for Reddit and most social platforms if your use case fits. More stable, less brittle, lower ban risk.

2. Deterministic browser automation second
   Use plain Playwright on a real logged-in browser profile, not agent-style tools. Modern editors are dynamic, but Playwright can still handle them if you target the actual composer carefully.

3. Human-in-the-loop fallback
   Generate the post automatically, then open the compose page and let a human click submit. This avoids a lot of anti-bot pain.

For Reddit specifically:

• If API access covers what you need, use that.
• If not, Playwright with a persistent profile is the next thing I’d try.
• I would not start with browser-use style agents for posting flows.

For social media in general:

• APIs beat browsers
• Browsers beat “AI agents clicking around”
• Avoid getting into a stealth/anti-detection arms race, it gets ugly fast

So the practical rule is: API where possible, Playwright where necessary, human approval for final submit when reliability matters.

If you want, I can give you a quick decision matrix for Reddit vs Twitter/X vs LinkedIn vs generic forum.

browser-use and camofox already use playwright as well I think

Yep, but that’s the important distinction:

“Built on Playwright” != “raw Playwright script”

browser-use and similar tools add a bunch of stuff on top:

• LLM planning / retry logic
• their own wait heuristics
• abstraction around elements/actions
• sometimes custom browser/fingerprinting behavior

That extra layer is often exactly what breaks flaky posting flows.

What I mean is:

• not “use another Playwright wrapper”
• use Playwright directly, with:
  • fixed selectors

• explicit waits
  • manual iframe/editor handling
  • persistent logged-in profile
  • maybe even CDP attach to your normal Chrome

So the stack I’d trust is:

1. Direct API, if available
2. Raw Playwright script against a real browser profile
3. Replay the exact network request, if the site is simple enough

If browser-use/camofox fail, I wouldn’t conclude “Playwright failed”, only that the wrapper approach failed.

If you want, I can show a minimal pattern for:

• raw Playwright + persistent profile
• or Playwright attached to existing Chrome/Brave via CDP

So if browser-use and camofox are useless for these kind of tasks, what would they be good for?

They’re not useless, I’d just use them for a different class of problem.

Good for:

• exploring an unfamiliar site
• extracting info from pages
• simple multi-step read-only tasks
• prototyping “can this workflow be automated at all?”
• internal tools / dashboards with low anti-bot pressure
• rough automation where 80 to 90 percent success is acceptable

Not great for:

• posting/submitting content reliably
• login-heavy flows
• sites with strong anti-bot checks
• anything account-sensitive
• production workflows where one bad click hurts

A simple mental model:

• browser-use = good for “figure out this UI and do some light work”
• camofox = useful when browser fingerprinting / detection is part of the problem
• raw Playwright/API = what you use when reliability actually matters

So I’d treat them more like recon/prototyping tools, not “final mile transaction tools”.

If you want, I can turn that into a quick rule of thumb like: “when to use browser-use vs Playwright vs API.”

yeah sure

Nice. My rough rule of thumb:

Use API when:

• the platform offers one
• you need reliability
• posting/account actions matter
• you want fewer breakages over time

Use raw Playwright when:

• there’s no API
• the workflow is fixed and known
• you need high success rate
• you can write selectors and waits yourself

Use browser-use when:

• you’re exploring a new UI
• the task is vaguely defined

• read-only or low-risk actions are fine
• you want fast prototyping more than reliability

Use camofox when:

• normal automation gets flagged
• fingerprinting/detection is the main issue
• you still accept that success may be inconsistent

My practical recommendation:

• Read/explore → browser-use
• Blocked by detection → try camofox
• Need dependable posting/submission → raw Playwright
• Need truly robust automation → API if at all possible

Short version: agents for discovery, scripts for execution, APIs for production.

If you want, I can also give you a site-type matrix:

• forum
• Reddit
• Twitter/X
• LinkedIn
• generic form-based website

So my target is mainly wordpress, since it can broadcast to a lot of social media, x/twitter and facebook mainly. What are you suggesting?

If WordPress is the hub, I would not use browser-use/camofox for the main workflow.

I’d suggest this setup:

Recommended stack

1. Post to WordPress via API

• Use the WordPress REST API
• For self-hosted WP, Application Passwords usually make this pretty easy
• This should be your source of truth

2. Syndicate outward from WordPress
Pick one of these routes:

• Plugin/service route
  Use a WordPress plugin or external scheduler/social tool to push posts out
  Good if you want less engineering

• Custom API route
  Your own small worker reads the WP post and sends to:
  • Facebook Pages API
  • X API if you have access
    Best if you want control/reliability

3. Use browser automation only as a fallback
Only for things like:

• weird admin UI actions
• media workflows with no API coverage
• one-off recovery/manual flows

Why this is better

• WordPress is API-friendly
• Social posting via browser is brittle
• X is especially annoying if you don’t have the proper API path