I hit the same wall 12 times in a row.
Playwright would open LinkedIn, bounce through the login screen, hesitate on the email field, trip over a redirect, and then my agent would start inventing reasons it “couldn’t proceed safely.” GitHub wasn’t much better. I kept thinking I had a model problem, so I did what most of us do first: better prompts, stricter instructions, smaller tasks, more retries.
None of it fixed the actual issue.
The turning point was realizing the browser agent wasn’t failing because it was dumb. It was failing because I had given it the wrong job. I was asking a browser loop to handle identity, consent, session management, redirects, and security checks as if those were just normal navigation steps.
While digging into this, I found a thread on r/openclaw about Conneclaw refusing to scrape LinkedIn: https://reddit.com/r/openclaw/comments/1tn8cq0/conneclaw_refuses_to_scrape_linkedin/. The complaint felt uncomfortably familiar. On the surface it looked like flaky model behavior, but the real problem was that LinkedIn login had become part of the browser loop.
That is the mistake.
If your browser MCP server or browser agent keeps failing on LinkedIn or GitHub login, I think prompt-tuning stops being useful after about the fifth retry. The reliable fix is to move authentication outside the browser loop. Use Playwright session state, OAuth, or the GitHub MCP server, then let the browser handle navigation only. In my case, removing login took the workflow from failing constantly to failing only rarely.
The reason this matters is simple: LinkedIn and GitHub login are not ordinary browsing tasks. They are identity tasks. They involve account authority, consent screens, MFA, redirect chains, device verification, bot detection, and all the little edge cases that make browser automation feel haunted.
People still hand the entire thing to a browser agent and then blame the model when it gets stuck. I think that’s backwards. Browser agents should not own primary account login for services like LinkedIn and GitHub. Not in Playwright, not in a browser MCP server, not in OpenClaw.
The failure pattern is almost boring once you notice it. The agent navigates correctly, reaches a login wall, gets caught in redirects or verification, and then you assume the model needs more help. So you spend more model calls trying to teach it how to click through an identity flow that was never a good fit for the browser loop in the first place.
That is where the hidden cost shows up.
In n8n, Zapier, Make, OpenClaw, or custom agent workflows, one bad login loop can poison an entire automation. A task that should have been “open page, extract data, continue” turns into 20 extra model calls, multiple retries, and a dead run that somehow still managed to burn time and budget.
I found another r/openclaw discussion about GitHub login that captured this perfectly: https://reddit.com/r/openclaw/comments/1tn88px/openclaw_b_liek_idk_how_to_sign_into_github_but/. The joke in the title is basically the architecture bug. The browser agent can look weirdly capable in one moment and then become the worst possible place to manage account authority in the next.
So what should own authentication instead? A dedicated authenticated path.
For GitHub, that usually means the GitHub MCP server or direct API access with the correct token and scope. For browser-heavy tasks, it can mean authenticating once with Playwright and reusing storageState carefully. For internal tools, it might mean handling OAuth outside the agent and then passing a constrained session into the workflow.
This is also where MCP is actually useful as a design idea, not just a buzzword. Browser navigation is one capability. Account authority is another. Mixing both into one loop is what creates chaos.
My opinionated version is this: if the task is “create a GitHub issue,” use the GitHub MCP server. If the task is “read a LinkedIn page after an approved session already exists,” use Playwright. If your browser agent is typing passwords into LinkedIn or GitHub on every run, the architecture is wrong.
Once I split navigation from account authority, the browser stopped acting cursed.
Playwright opened the page, navigated, extracted what I needed, and moved on. GitHub actions went through the GitHub MCP server instead of pretending a browser tab was a secure identity layer. The agent was doing less, but the system as a whole was doing more.
That was the part I didn’t appreciate at first. This wasn’t just a cleaner design. It made the automation boring in the best possible way, which is exactly what you want when something is supposed to run over and over without supervision.
And if you run long-lived agents, boring is expensive to ignore.
Repeated login loops create a tax on everything around them: more retries, more latency, more brittle runs, and more model calls wasted on the same dead-end screen. They also create cost anxiety, because every failed loop feels like watching tokens disappear while no useful work is happening.
That’s one reason this problem matters beyond debugging. Teams often read these failures as a sign that they need a smarter model, when the real fix is to stop using the browser as their identity system. Better architecture beats more prompt massaging almost every time here.
It also changes how you think about compute.
If your automations are constantly rerunning fragile browser flows, usage-based billing turns every architectural mistake into a finance problem. Every extra retry, every dead-end login screen, every “just one more prompt tweak” has a visible cost attached to it. That tends to push teams into under-automating or constantly monitoring usage instead of fixing the workflow properly.
That’s a big reason products like Standard Compute are interesting for agent-heavy setups. If you’re running automations in n8n, Make, Zapier, OpenClaw, or custom schedulers, a flat monthly model changes the way you debug and operate. You can afford to run the workflow enough times to find the real bottleneck, and in cases like this, the bottleneck usually isn’t the model. It’s the fact that the browser was handed a job it never should have owned.
So yes, the title is exactly what happened.
My browser MCP server stopped fighting LinkedIn the second I stopped making it do login. Not because Playwright suddenly got smarter, and not because the model had some breakthrough. It got better because I finally stopped asking Playwright, LinkedIn, GitHub, and MCP to do the wrong job in the same place.