Summary
gstack browse runs inside an environment with standard proxy env vars set (HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY), but page navigation still fails because the Playwright Chromium launch paths do not explicitly pass proxy settings.
Observed behavior
On a machine where:
- Claude Code itself can use the global proxy successfully
curl through the same proxy succeeds
- local proxy endpoints are healthy
these commands fail with browser-level navigation errors:
browse goto https://www.google.com
browse goto https://duckduckgo.com
Error:
net::ERR_CONNECTION_RESET
Root cause
browse/src/browser-manager.ts launches Chromium via Playwright in multiple code paths, but does not pass Playwright's proxy option derived from the standard env vars:
chromium.launch(...)
chromium.launchPersistentContext(...)
- handoff / context recreation
launchPersistentContext(...)
As a result, some surrounding process/network logic may see proxy env vars, but the actual Chromium page-navigation layer does not reliably use them.
Expected behavior
If standard proxy env vars are present, gstack browse should use them for Chromium navigation too.
Proposed fix
Add a small helper in BrowserManager that reads:
HTTPS_PROXY / https_proxy
HTTP_PROXY / http_proxy
ALL_PROXY / all_proxy
NO_PROXY / no_proxy
and inject the resulting Playwright proxy config into all Chromium launch paths.
Validation
After patching and rebuilding locally, the following succeeded:
browse goto https://www.google.com # 200
browse goto https://duckduckgo.com # 200
Summary
gstack browseruns inside an environment with standard proxy env vars set (HTTP_PROXY,HTTPS_PROXY,ALL_PROXY,NO_PROXY), but page navigation still fails because the Playwright Chromium launch paths do not explicitly pass proxy settings.Observed behavior
On a machine where:
curlthrough the same proxy succeedsthese commands fail with browser-level navigation errors:
Error:
Root cause
browse/src/browser-manager.tslaunches Chromium via Playwright in multiple code paths, but does not pass Playwright'sproxyoption derived from the standard env vars:chromium.launch(...)chromium.launchPersistentContext(...)launchPersistentContext(...)As a result, some surrounding process/network logic may see proxy env vars, but the actual Chromium page-navigation layer does not reliably use them.
Expected behavior
If standard proxy env vars are present,
gstack browseshould use them for Chromium navigation too.Proposed fix
Add a small helper in
BrowserManagerthat reads:HTTPS_PROXY/https_proxyHTTP_PROXY/http_proxyALL_PROXY/all_proxyNO_PROXY/no_proxyand inject the resulting Playwright
proxyconfig into all Chromium launch paths.Validation
After patching and rebuilding locally, the following succeeded: