Repository navigation
fix(ide): surface explicit gVisor sandbox network isolation error - #29665
elberthc-byte wants to merge 6 commits into
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 addresses connectivity issues between the IDE and sandboxed environments, specifically targeting gVisor (runsc) isolation. By ensuring critical environment variables are correctly propagated and updating host header validation, the changes allow for more reliable communication. Additionally, the PR introduces better diagnostics to help users distinguish between configuration errors and inherent sandbox network restrictions. 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 the 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 counterproductive. 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
|
|
📊 PR Size: size/L
|
There was a problem hiding this comment.
Code Review
This pull request implements forwarding of IDE mode environment variables to LXC and gVisor (runsc) sandbox environments, updates the VS Code companion server to allow container host headers, and improves error reporting for gVisor network isolation. The review feedback highlights a critical security vulnerability where forwarding the sensitive GEMINI_CLI_IDE_AUTH_TOKEN into the sandbox could allow an untrusted process to escape to the host's IDE companion server. Additionally, it is recommended to centralize the gVisor sandbox detection logic into a helper function to avoid scattering environment variable normalization across multiple files.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request adds support for forwarding IDE-related environment variables to LXC and gVisor (runsc) sandboxes, and introduces specific error handling for gVisor network isolation when connecting to the IDE companion. Additionally, it updates the VS Code companion server to allow container host headers. Feedback on the changes includes a style guide violation in the tests where process.env is modified directly instead of using vi.stubEnv.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request adds support for forwarding IDE mode environment variables (specifically STDIO command and arguments) to LXC and gVisor (runsc) sandboxes. It also handles gVisor's strict network isolation by providing explicit error messages when attempting to connect to the IDE companion extension, and updates the VS Code companion server to allow requests from container host headers (host.docker.internal and host.containers.internal). Comprehensive unit tests have been added to verify these behaviors. I have no feedback to provide as there are no review comments.
Trim PR google-gemini#29665 to the minimal change needed for google-gemini#21331 and harden its tests. - sandbox.ts: inject GEMINI_SANDBOX=runsc only when the sandbox command is runsc; stop forwarding GEMINI_CLI_IDE_SERVER_STDIO_COMMAND/ARGS (host paths are meaningless inside the container) - revert the companion Host allowlist change (unrelated to gVisor; tracked as a follow-up with the Linux Docker IDE issues) - isGvisorSandbox(): single documented signal (GEMINI_SANDBOX), no container-name heuristic - IdeClient.connect(): message now states both cause and remedy - tests: mocked connect() matrix in ide-client.test.ts (incl. "still connects when reachable"), isGvisorSandbox() table, hermetic real-socket regression test (refused loopback port + isolated TMPDIR instead of DNS and fs mocks), launcher tests assert real --env pairs and that the auth token and stdio command are never forwarded - docs: drop the "use docker instead" recommendation, which is not reliable on Linux either
Summary
When Gemini CLI runs inside a gVisor (
runsc) sandbox, the IDE companion server on the host can't be reached: gVisor's user-space network stack isolates the container from the host loopback interface. Today the CLI reports the generic… To install the extension, run /ide install., which is misleading (the extension is installed and running) and sends users down the wrong debugging path.This PR makes the CLI name the actual cause and the remedy, and documents the limitation. It is intentionally a diagnostic + documentation fix; it does not try to bridge the sandbox network (see Non-goals).
Details
packages/cli/src/utils/sandbox.ts— when the sandbox command isrunsc, injectGEMINI_SANDBOX=runscinto the container so the CLI inside knows which runtime launched it. This mirrors the macOSsandbox-execpath, which already forwardsGEMINI_SANDBOX. It can't trigger nested sandboxing:getSandboxCommand()returns early wheneverSANDBOXis set inside a container. No other environment variables are added, andGEMINI_CLI_IDE_AUTH_TOKENis still never forwarded.packages/core/src/ide/ide-connection-utils.ts— newisGvisorSandbox()with a single documented signal (GEMINI_SANDBOX, normalized, equalsrunsc).packages/core/src/ide/ide-client.ts—connect()now reportsFailed to connect to IDE companion extension in <IDE>: gVisor (runsc) sandboxing isolates the container network stack, so the IDE companion server on the host is unreachable. To use IDE integration, run Gemini CLI without the runsc sandbox.when running under gVisor and (a) the HTTP/stdio connection attempts fail, or (b) no workspace path reaches the sandbox (the case that previously produced the
/ide installadvice).Directory mismatchandopen a workspace foldererrors are unchanged, and connection attempts are still made, so a reachable companion still connects.docs/cli/sandbox.md(runsc limitations) anddocs/ide-integration/index.md(sandboxing note and troubleshooting entry).Non-goals / follow-ups
runsc. That needs a host-side bridge or forwarding the IDE auth token into the sandbox; the latter was rejected for security reasons (fix(cli): forward IDE auth token and accept container host header for sandboxed IDE connections #29653).127.0.0.1only (sohost.docker.internal→host-gatewayis refused), the auth token is never forwarded, and the companion's Host allowlist rejects container origins. Thedocs/ide-integration/index.mdclaim that it "can still connect" is stale. This is pre-existing and will be tracked in a separate issue.Related Issues
Fixes #21331
How to Validate
runscneeded):src/ide/ide-gvisor-sandbox.test.tsfails onmainwith… run /ide install.and passes with this PR.SANDBOXset prevents a relaunch; port1is a refused loopback port):/ide enableand confirm the status reads🔴 Disconnected: Failed to connect to IDE companion extension in VS Code: gVisor (runsc) sandboxing isolates the container network stack, …. Repeat withGEMINI_SANDBOX=dockerto confirm the generic/ide installmessage is unchanged.runscDocker runtime): from a VS Code terminal with the companion installed, runGEMINI_SANDBOX=runsc NODE_ENV=development npm run start, then/ide enable.Pre-Merge Checklist