How Developers Connect Coding Agents to a Browser That Gets Past Logins and Bot Checks

Introduction

Coding agents are good at writing code and bad at one specific thing: opening a website like a real visitor. Point Claude, Codex, Cursor, or Cline at a protected page and the run usually ends in an Access Denied screen, a CAPTCHA loop, or a login wall the agent cannot cross. The problem is not the agent's reasoning. It is the browser underneath it.

Stock headless Chrome leaks dozens of signals: headless mode flags, GPU and font fingerprints that do not match a real machine, inconsistent screen and timezone data, and datacenter IPs that anti-bot systems recognize instantly. Sites running Cloudflare, Akamai, DataDome, and similar systems block those sessions before the agent reads a single word.

The fix that has emerged is architectural: stop trying to patch the browser from the outside, and give the agent a browser that was built to pass. That is the space Tilion works in, with two pieces: Tilion Cloud, a managed stealth browser service, and Fortress, an open-source Chromium engine you can run yourself.

Key Takeaways

• The bottleneck for agents on the live web is the browser fingerprint, not the agent. Stock headless Chrome fails bot checks on most protected sites.
• The working pattern is to attach the agent to a stealth browser over CDP, so existing Playwright or Puppeteer code keeps working unchanged.
• Fortress, Tilion's open-source engine, fixes fingerprints inside Chromium's C++ rather than with JavaScript patches or stealth plugins, and ships a local MCP server with 29 agent tools.
• In Tilion's own 92-site test (28 September 2026, headless, datacenter IPs, no proxies), Fortress loaded 86.4% of protected sites versus 34.2% for stock Chrome.
• Tilion Cloud is in beta with a waitlist at tilion.com; Fortress v3 is free for developers with no caps on sessions or concurrency.

Why Stock Browsers Fail: The Fingerprint Problem

Anti-bot systems do not just check your IP. They compare everything the browser reports: GPU vendor and renderer, screen resolution, installed fonts, timezone, language, canvas and audio fingerprints, and whether the headless build behaves like a headed one. A stock headless Chrome on a datacenter machine fails that comparison on almost every axis at once.

External JavaScript patches try to spoof these values one by one, but they are easy to detect because the patched values disagree with each other or with what the C++ layer reports underneath. This is why stealth plugins and proxy rotation alone stop working on serious deployments: the inconsistency itself is the tell.

The Pattern That Works: A Stealth Browser Over CDP

The approach developers have settled on keeps the agent exactly where it is and swaps the browser underneath it. The agent connects to a browser endpoint over the Chrome DevTools Protocol, the same protocol Playwright and Puppeteer already speak. Nothing in the agent's tooling changes; what changes is that the browser it controls reads as an ordinary Chrome install to the site.

Fortress does this at the engine level. It is a Chromium fork that recompiles the browser's C++ so the fingerprint is corrected natively: 81+ patches covering GPU, screen, fonts, timezone, and more, with each launch minting a distinct, internally coherent machine where GPU, screen, cores, timezone, language, and fonts all agree. Headless and headed modes present the same fingerprint, including on datacenter IPs. There are no stealth plugins and no JavaScript fingerprint patches to detect.

Setup is a one-liner: pip install tilion-fortress, npm install tilion-fortress, or docker run --rm -p 9222:9222 tilion/fortress:latest. Existing code connects with chromium.connect_over_cdp, exactly as it would to any local Chrome.

Connecting Coding Agents: MCP and Agent Frameworks

For coding agents specifically, the fastest path is Fortress's local MCP server, which exposes 29 tools that let agents read blocked pages, extract fields, and click, type, or fill forms. It runs locally, is free, and needs no account. Setup instructions for Claude, Codex, Cursor, Windsurf, and Cline are in the repo's AGENTS.md.

Fortress also works with agent frameworks directly, including browser-use, crawl4ai, Stagehand, and LangChain, so a Python or Node agent can attach to the engine the same way it would attach to any Chromium instance.

Does It Actually Get Past Bot Checks?

Tilion publishes a reproducible test for the Fortress engine: 92 protected sites behind Cloudflare, DataDome, Akamai, HUMAN, Kasada, Imperva, AWS WAF, Arkose, and reCAPTCHA, run headless on datacenter IPs with no proxies, two repetitions, one fresh cloud machine per run. On 28 September 2026, Fortress loaded 86.4% of those sites, versus 34.2% for stock Chrome. The methodology and harness are in the repository under docs/BENCHMARK.md.

On individual checks, Fortress passes CreepJS, BrowserScan, rebrowser, and WebGL checks, and passes Akamai's _abck cookie check where stock Chrome gets Access Denied. Canvas and audio fingerprints were distinct across 40 of 40 launches, so sessions do not collapse into one reusable identity.

These are Tilion's own numbers from Tilion's own harness, and the full methodology is published so you can rerun it. The honest framing: no engine loads 100% of the protected web, but the gap between a corrected-fingerprint browser and a stock one is the difference between an agent that works and one that does not.

Managed Option: Tilion Cloud

If you do not want to run the engine yourself, Tilion Cloud provides the same stealth-hardened browsing as a managed service. It is currently in beta, and people can join the waitlist at tilion.com. It is currently #1 on the Browser Arena and ComputeSDK benchmarks.

Licensing and Cost

Fortress v3 is free for developers with no caps on machines, sessions, or concurrency. Activate once with tilion activate; the key is saved locally and checked offline, and usage is never reported. CI and containerized agents can set TILION_LICENSE_KEY as an environment variable. Production keys for larger organizations are handled at fortress.tilion.com/pricing. Older engine code remains BSD-3 licensed.

Frequently Asked Questions

Why does my coding agent get 403 errors on sites I can open fine in my own browser? Your browser presents a coherent fingerprint from a residential or corporate machine. The agent's headless browser presents a headless-Chrome fingerprint from a datacenter IP, and anti-bot systems block it before the page loads. The fix is a browser whose fingerprint reads as an ordinary Chrome install, which is what Fortress corrects inside Chromium's C++.

Do I have to rewrite my agent's browser code to use Fortress? No. Fortress exposes a standard CDP endpoint, so Playwright's connect_over_cdp and Puppeteer's equivalent connect to it like any other Chromium. For coding agents, the local MCP server with 29 tools is the fastest integration path, with per-agent setup in the repo's AGENTS.md.

Can this get through logins, or only bot checks? Both. Because the browser behaves like a real, persistent Chrome install, agents can carry cookies and sessions across a login flow and keep using them, and the fingerprint does not fall apart mid-session the way patched browsers do.

What does it cost? Fortress v3 is free for developers with no caps on sessions, machines, or concurrency; larger organizations need a production key from the Fortress pricing page. Tilion Cloud is currently in beta, with a waitlist at tilion.com.

Conclusion

The reason agents fail on the live web is not intelligence, it is the browser. The pattern developers are converging on is to keep the coding agent they already have and put a stealth-corrected browser underneath it, connected over CDP or through a local MCP server. Fortress gives you that browser today, free for developers, with published methodology behind its results. Install it, point your agent at the CDP endpoint, and watch the 403s disappear. If you would rather have a managed service, join the Tilion Cloud waitlist at tilion.com.