feat(browser): add sandbox-aware browser agent initialization#24419
feat(browser): add sandbox-aware browser agent initialization#24419gsquared94 merged 4 commits intogoogle-gemini:mainfrom
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces environment-aware initialization for the browser agent to ensure compatibility when running within sandboxed environments like macOS Seatbelt or containers (Docker/Podman). The changes ensure that the agent gracefully handles restricted filesystem access and network limitations by adjusting configuration parameters and providing clear feedback to the user when specific modes are required. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces sandbox-aware logic for the browser agent to improve compatibility with Seatbelt (macOS) and containerized environments like Docker. In Seatbelt sandboxes, the agent now forces isolated and headless modes, while in container sandboxes, it requires an "existing" session mode and resolves the host IP to connect to Chrome's DevTools protocol. Feedback was provided regarding the hardcoded port 9222, suggesting it should be made configurable within the browser agent settings.
| `Could not resolve host.docker.internal, using hostname directly`, | ||
| ); | ||
| } | ||
| const browserUrl = `http://${browserHost}:9222`; |
There was a problem hiding this comment.
The remote debugging port 9222 is hardcoded. While this is a common default, it should be configurable to support environments where a different port is used for security or to avoid conflicts. This is especially relevant for the container-based connection this PR is adding.
I recommend adding a remoteDebuggingPort property to BrowserAgentCustomConfig in packages/core/src/config/config.ts and using it here.
Example implementation:
// In packages/core/src/config/config.ts
export interface BrowserAgentCustomConfig {
// ... existing properties
remoteDebuggingPort?: number;
}// In this file (packages/core/src/agents/browser/browserManager.ts)
const remoteDebuggingPort = this.config.getBrowserAgentConfig().customConfig.remoteDebuggingPort ?? 9222;
const browserUrl = `http://${browserHost}:${remoteDebuggingPort}`;There was a problem hiding this comment.
Will keep as-is unless it's brought up as a pain-point later on.
There was a problem hiding this comment.
maybe mention in readme that it is a hard coded port number that user cannot customize it for now
gemini-cli
bot
added
the
status/need-issue
cynthialong0-0
left a comment
cynthialong0-0
left a comment
There was a problem hiding this comment.
LGTM pending on a few nits.
| `Could not resolve host.docker.internal, using hostname directly`, | ||
| ); | ||
| } | ||
| const browserUrl = `http://${browserHost}:9222`; |
There was a problem hiding this comment.
maybe mention in readme that it is a hard coded port number that user cannot customize it for now
- Gate browser agent registration in container sandboxes unless sessionMode is set to 'existing' (registry.ts) - Force isolated+headless mode in macOS seatbelt sandboxes for filesystem compatibility (browserManager.ts) - Auto-configure --browser-url with DNS-resolved host IP for container sandboxes, working around Chrome's DevTools Host header restriction (browserManager.ts) - Add 8 integration tests covering all sandbox overrides and registration gating
…ser port limitation
The CI workflow sets SANDBOX='sandbox:none' as metadata on macOS and Windows runners. The isContainerSandbox check treated this as a real container sandbox, causing browser-policy E2E tests to fail.
gsquared94
force-pushed
the
feat/browser-agent-sandbox-mode
branch
from
9a0cae5 to
759853b
Compare
2 participants
Summary
Add environment-aware initialization for the browser agent to support macOS Seatbelt and container-based (Docker/Podman) sandboxes. Previously, the browser agent would fail with permission errors or
DevToolsActivePortcrashes when running inside sandboxed environments.Changes
Registration Gating (
registry.ts)sessionModeis set to"existing"Sandbox-Aware Configuration (
browserManager.ts)sandbox-exec): Forceisolated+headlessmodes for filesystem compatibility (persistent profiles conflict with seatbelt restrictions)sessionMode: "existing", auto-configure--browser-urlwith the resolved IP ofhost.docker.internalinstead of--autoConnect(which fails in containers due to local pipe/socket restrictions)host.docker.internalto IP viadns.promises.lookup()because Chrome's DevTools protocol rejects HTTP requests where theHostheader is notlocalhostor an IP addressTests
Environment Detection
SANDBOX=sandbox-exec→ macOS SeatbeltSANDBOX=<container-name>→ Docker/Podman/gVisor/LXC containerTesting