Replace the agentic browser fleet's Chromium engine with Fortress - #298
Merged
Conversation
…illa Playwright Chromium x64 from tiliondev/fortress's official v151.0.7908.0 release. arm64 has no official release yet (tiliondev/fortress#28 is open, not merged), so this points at a community fork build in the meantime -- swap to the official release once that PR lands. Both hashes verified against the actual downloaded tarballs, not copied from a description. session.py wiring (pointing the fleet's launch path at the new binary) is a separate follow-up -- this PR only gets the binary onto disk. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Completes the deferred_install.sh swap from the previous commit: - session.py: _FORTRESS_MARKER/_FORTRESS_EXECUTABLE replace _PLAYWRIGHT_MARKER/playwright.chromium.executable_path -- the fleet now launches Fortress, not Playwright's own managed Chromium. - CLAUDE.md: agents' own direct Playwright calls (sync_playwright().chromium .launch()) now need executable_path pointed at Fortress too, same engine everywhere in the workspace. - apps/system_interface's E2E tests and .github/workflows/ci.yml are deliberately untouched -- different machine (GitHub Actions), never reads this marker or path, testing the chat UI itself with plain Chromium is correct there. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The prior linux-arm64-151.0.7908.0 build targeted the wrong Debian; swap to linux-arm64-151.0.7908.0-debian12. Asset renamed with a -debian12 suffix and SHA256 updated to match the new tarball (verified against the release SHA256SUMS). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
|
you'll need to make the fork a fork from our org (not your github username) |
Contributor
|
assuming this was tested and works, lgtm (after we fix the location of the fork) |
… fork Re-hosted the debian12 aarch64 tarball on minhtrinh-imbue/fortress (identical file, same sha256 da6965af...) and repointed _FORTRESS_ARM64_URL there, off the personal MT-GoCode account. Verified end-to-end: the new URL downloads and its sha256 matches the pinned value. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
minhtrinh-imbue
added a commit
that referenced
this pull request
Jul 25, 2026
Resolves conflicts from PR #298 (Fortress) landing on main: - deferred_install.sh: main()) runs _install_fortress (engine, from main) + my _install_xvfb. - session.py: use the Fortress marker/executable (from main) and keep my Xvfb marker; deferred_install_ready gates on both; _build_bu_session launches the Fortress binary headful under Xvfb. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
libs/browser) now drives Fortress (tiliondev/fortress) -- a from-source, fully open (BSD-3) stealth-patched Chromium fork -- instead of Playwright's own managed Chromium.scripts/deferred_install.shfetches the right binary per-arch: x64 from Fortress's own officialv151.0.7908.0release, arm64 from a community fork build (MT-GoCode/fortress, Add native linux/arm64 (aarch64) build support tiliondev/fortress#28 -- native arm64 support is open upstream but not merged yet). Both hashes verified against the actual downloaded tarballs.session.pyandCLAUDE.md(agents' own direct Playwright calls) both now point at the same Fortress binary -- one engine everywhere in the workspace, matching the existing single-engine design.apps/system_interface's E2E tests and CI are deliberately untouched -- different machine (GitHub Actions), never reads this marker/path.Why Fortress over CloakBrowser (the prior approach)
A previous PR (#290, closed) used CloakBrowser as a stopgap specifically because Fortress had no arm64 build. That's resolved -- a native arm64 Fortress build now exists and has been verified running on real aarch64 hardware (loads pages, projects the spoofed persona correctly). Fortress has stronger stealth claims (0% CreepJS, published gauntlet, monthly rebase) and no free-tier version staleness, unlike CloakBrowser's paywalled-latest-major model.
Test plan
libs/browser/browser_test.py-- full suite passes (64/64)libs/browser/test_browser_integration.py(non-integration subset) -- passesbash -n scripts/deferred_install.sh-- valid syntaxtilion-fortress/tilion) and SHA256, not assumed from docsdeferred_install.shend-to-end, and a live fleet browser launch against the Fortress binary specifically (the CDP/browser_use integration path)Follow-ups (deliberately out of scope here)
slice_provider.py) still bakes vanilla Chromium -- needs the same swap in a separate PR._FORTRESS_ARM64_URL/_FORTRESS_ARM64_SHA256indeferred_install.shfrom the community fork to the official release.🤖 Generated with Claude Code