I hit the same wall 12 times in a row: Playwright opened LinkedIn, bounced through the login screen, hesitated on the email field, tripped over a redirect, and then my agent started inventing reasons it "couldn't proceed safely." GitHub was no better. I tried the obvious fixes first—better prompts, stricter step-by-step instructions, smaller tasks, more retries. None of it mattered. The turning point was realizing the browser agent was failing because I had given it the wrong job.
While researching this, I came across a thread on r/openclaw about Conneclaw refusing to scrape LinkedIn. The complaint sounded familiar: the model looked flaky, but the real issue 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, stop prompt-tuning it after the 5th 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 cut repeated failures from every run to almost none.
Why do browser MCP servers keep failing on LinkedIn and GitHub login?
Because LinkedIn and GitHub login are not normal browsing tasks. They are identity, consent, session, and security tasks.
That sounds obvious, but people still hand the whole thing to a browser agent and then blame the model when it gets stuck. I think that is 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. Prompt-tuning this problem is the wrong fix.
The failure pattern is always the same:
- The agent navigates correctly.
- It reaches a login wall with redirects, MFA, bot checks, or consent screens.
- You assume the model is weak.
- You burn more model calls trying to teach it to click through identity flows.
- The workflow gets slower, more expensive, and less reliable.
That is especially painful in n8n, Zapier, Make, OpenClaw, and custom agent workflows where 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 and a dead run.
I found another r/openclaw discussion about GitHub login that captured the absurdity perfectly. The joke in the title is basically the whole problem: the browser agent can appear to know a lot about your environment, yet still be the worst possible place to manage account authority.
What should own authentication instead of the browser agent?
A dedicated authenticated path.
For GitHub, that usually means the GitHub MCP server or direct API access with the right token and scope. For browser-heavy tasks, it can mean authenticating once with Playwright and reusing storageState carefully. For internal tools, it might mean OAuth handled outside the agent, then passing a constrained session into the workflow.
The Model Context Protocol (MCP) points in the same direction: tools should expose capabilities with clear authority boundaries. Browser navigation is one capability. Account authority is another. Mixing them into one loop is what creates chaos.
Here is the opinionated version: if the task is "create a GitHub issue," use the GitHub MCP server. If the task is "read a LinkedIn page after an already-approved session exists," use Playwright. If your browser agent is typing passwords into LinkedIn or GitHub on every run, your architecture is wrong.
What changed after I split navigation from account authority?
The browser stopped acting haunted.
Once I removed login from the browser agent's job, the rest of the workflow got boring in the best way. 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 did less, but the system did more.
That is the part people miss. This is not just about elegance. It is about reliability for long-running automations.
If you run agents in n8n, Make, Zapier, OpenClaw, or your own scheduler, repeated login loops are a tax on everything:
- more retries
- more latency
- more brittle runs
- more model calls wasted on the same dead-end screen
- more cost anxiety because the workflow keeps burning tokens without doing useful work
The irony is that teams often interpret those failures as a reason to buy smarter models, when the real fix is to stop using the browser as your identity system.
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 the model suddenly got smarter. Because I finally stopped asking Playwright, LinkedIn, GitHub, and MCP to do the wrong job in the same place.