Skip to content

Comments

fix(tools): remove BrowserToolSet from package init to reduce downstream bundle size#2197

Open
malhotra5 wants to merge 2 commits intomainfrom
remove-browser-use-from-init
Open

fix(tools): remove BrowserToolSet from package init to reduce downstream bundle size#2197
malhotra5 wants to merge 2 commits intomainfrom
remove-browser-use-from-init

Conversation

@malhotra5
Copy link
Collaborator

@malhotra5 malhotra5 commented Feb 24, 2026

Summary

Remove the direct import of BrowserToolSet from openhands/tools/__init__.py to avoid forcing downstream consumers to bundle the browser-use package and its heavy dependencies.

Problem

The OpenHands-CLI project (PR #527) bumped the SDK to v1.11.5, which caused all binary tests to fail. The root cause was that openhands/tools/__init__.py now imports BrowserToolSet at the package level:

from openhands.tools.browser_use import BrowserToolSet

This means any import of openhands.tools transitively imports the browser-use package and all its dependencies. For PyInstaller bundles (like OpenHands-CLI), this:

  1. Forces bundling of browser-use and its dependency tree (playwright, etc.)
  2. Increases binary size unnecessarily for users who don't need browser automation
  3. Caused crashes when browser-use was excluded from the bundle (the previous workaround)

The CLI had to work around this by including browser-use in the PyInstaller spec, but this is not ideal.

Solution

Remove BrowserToolSet from the package-level __init__.py. Users who need browser tools can still import them directly:

from openhands.tools.browser_use import BrowserToolSet

This is consistent with how other optional/heavy features should be handled - explicit imports for optional dependencies.

Changes

  • Removed BrowserToolSet import from openhands/tools/__init__.py
  • Removed BrowserToolSet from __all__
  • Added a docstring note explaining why browser tools are not re-exported

Backward Compatibility

This is a minor breaking change for code that imports BrowserToolSet via:

from openhands.tools import BrowserToolSet  # Will no longer work

The fix is straightforward:

from openhands.tools.browser_use import BrowserToolSet  # Use this instead

Related

@malhotra5 can click here to continue refining the PR


Agent Server images for this PR

GHCR package: https://github.com/OpenHands/agent-sdk/pkgs/container/agent-server

Variants & Base Images

Variant Architectures Base Image Docs / Tags
java amd64, arm64 eclipse-temurin:17-jdk Link
python amd64, arm64 nikolaik/python-nodejs:python3.12-nodejs22 Link
golang amd64, arm64 golang:1.21-bookworm Link

Pull (multi-arch manifest)

# Each variant is a multi-arch manifest supporting both amd64 and arm64
docker pull ghcr.io/openhands/agent-server:2a5ace5-python

Run

docker run -it --rm \
  -p 8000:8000 \
  --name agent-server-2a5ace5-python \
  ghcr.io/openhands/agent-server:2a5ace5-python

All tags pushed for this build

ghcr.io/openhands/agent-server:2a5ace5-golang-amd64
ghcr.io/openhands/agent-server:2a5ace5-golang_tag_1.21-bookworm-amd64
ghcr.io/openhands/agent-server:2a5ace5-golang-arm64
ghcr.io/openhands/agent-server:2a5ace5-golang_tag_1.21-bookworm-arm64
ghcr.io/openhands/agent-server:2a5ace5-java-amd64
ghcr.io/openhands/agent-server:2a5ace5-eclipse-temurin_tag_17-jdk-amd64
ghcr.io/openhands/agent-server:2a5ace5-java-arm64
ghcr.io/openhands/agent-server:2a5ace5-eclipse-temurin_tag_17-jdk-arm64
ghcr.io/openhands/agent-server:2a5ace5-python-amd64
ghcr.io/openhands/agent-server:2a5ace5-nikolaik_s_python-nodejs_tag_python3.12-nodejs22-amd64
ghcr.io/openhands/agent-server:2a5ace5-python-arm64
ghcr.io/openhands/agent-server:2a5ace5-nikolaik_s_python-nodejs_tag_python3.12-nodejs22-arm64
ghcr.io/openhands/agent-server:2a5ace5-golang
ghcr.io/openhands/agent-server:2a5ace5-java
ghcr.io/openhands/agent-server:2a5ace5-python

About Multi-Architecture Support

  • Each variant tag (e.g., 2a5ace5-python) is a multi-arch manifest supporting both amd64 and arm64
  • Docker automatically pulls the correct architecture for your platform
  • Individual architecture tags (e.g., 2a5ace5-python-amd64) are also available if needed

…size

Remove the direct import of BrowserToolSet from openhands/tools/__init__.py
to avoid forcing downstream consumers to bundle the browser-use package
and its heavy dependencies.

Users who need browser tools can still import directly from
openhands.tools.browser_use.

Related: OpenHands/OpenHands-CLI#527

The OpenHands-CLI had to include browser-use in its PyInstaller bundle
because importing openhands.tools now transitively imports browser_use.
This increased the binary size unnecessarily for CLI users who don't
need browser automation features.

Co-authored-by: openhands <openhands@all-hands.dev>
@github-actions
Copy link
Contributor

github-actions bot commented Feb 24, 2026

API breakage checks (Griffe)

Result: Passed

Action log

@malhotra5 malhotra5 marked this pull request as ready for review February 24, 2026 18:50
Remove the assertion for BrowserToolSet from the top-level exports test
since it's no longer exported from openhands.tools.__init__.py.

Co-authored-by: openhands <openhands@all-hands.dev>
Copy link
Collaborator

@all-hands-bot all-hands-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Good taste - Pragmatic fix for a real production problem. Follows Python best practices for optional dependencies.

Key insight: Heavy optional dependencies belong behind explicit imports, not transitively loaded at package level. This is exactly how it should be done.

@github-actions
Copy link
Contributor

Coverage

Coverage Report •
FileStmtsMissCoverMissing
openhands-tools/openhands/tools
   __init__.py12283%35–36
TOTAL18758952449% 

@enyst enyst self-requested a review February 24, 2026 19:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants