Supervisor L7 proxy should support HTTP_PROXY/HTTPS_PROXY for corporate environments

Problem Statement

Problem

In corporate/enterprise Kubernetes clusters, nodes do not have direct internet access. All outbound traffic must go through a corporate forward proxy (e.g., Squid, Zscaler). The supervisor's L7 proxy does not respect HTTP_PROXY, HTTPS_PROXY, or NO_PROXY environment variables, causing all external API calls from agents (e.g., Tavily search, Stripe, external MCP servers) to fail with connection timeouts.

Current Behavior

The agent process has HTTP_PROXY=http://10.200.0.1: pointing to the supervisor
The supervisor intercepts outbound traffic and applies policy
After policy approval, the supervisor connects directly to the destination
In proxy-required environments, this direct connection fails (no route to host / connection timeout)

Proposed Design

Desired Behavior
The supervisor should:

Read HTTPS_PROXY / HTTP_PROXY / NO_PROXY from its own environment variables
When policy allows an outbound connection, route it through the configured corporate proxy using HTTP CONNECT
Respect NO_PROXY for cluster-internal destinations (e.g., *.svc.cluster.local, 10.96.0.0/12)
Ideally configurable per-sandbox via the Sandbox CRD:

spec:
  podTemplate:
    spec:
      containers:
      - name: agent
        env:
        - name: HTTPS_PROXY
          value: "http://proxy.corp.com:8080"
        - name: NO_PROXY
          value: "*.svc.cluster.local,10.0.0.0/8"

Alternatives Considered

Use Case

Large enterprise deployments where all Kubernetes clusters are behind corporate proxies. Without this, agents cannot access any external API (search tools, SaaS APIs, external MCP servers) even when policy allows it.

Workaround

None currently viable. We've explored adding a second proxy container but the supervisor rewrites the agent's proxy env to point to itself, overriding any custom configuration.

Agent Investigation

No response

Checklist

I've reviewed existing issues and the architecture docs
This is a design proposal, not a "please build this" request

📋 triage-agent

Triage Assessment

Classification: needs-investigation

Summary

This is a valid enterprise deployment gap. OpenShell forces sandbox workloads to use the local policy proxy, but after policy approval the supervisor opens direct upstream sockets. In proxy-required enterprise clusters, allowed external API calls can therefore still fail after policy allows them.

Investigation

The workload proxy environment is overwritten to point at the local OpenShell proxy, with NO_PROXY limited to local addresses. ProxyPolicy only models the local listener, and the CONNECT plus plain HTTP forward paths resolve the destination for SSRF checks and then dial it directly with TcpStream::connect. TLS inspection wraps that direct upstream socket, so corporate proxy support needs an explicit upstream-dial path rather than relying on inherited HTTP_PROXY variables. Related issues are adjacent but not duplicates: #785 is gateway/K3s startup proxying, #1107 is raw TCP hostname resolution, and #155/#59 are private-IP and forward-proxy work.

Recommendation

Route this to a spike before implementation. The spike should define upstream proxy configuration, NO_PROXY matching, HTTP CONNECT chaining, proxy credential handling, SSRF and DNS semantics when a corporate proxy performs resolution, and tests for CONNECT, plain HTTP forward proxying, TLS-inspected relay, and Kubernetes environment propagation.

Suggested labels: spike, area:supervisor, area:sandbox. Do not apply state:agent-ready; that remains a human gate.

feat(sandbox,podman): chain sandbox egress through corporate HTTP proxy

feat(sandbox,podman): trust corporate CA for TLS to https:// proxies

Spike resolution: corporate proxy chaining implemented and validated on the Podman driver

The questions the triage assessment routed to a spike have been answered with a working
implementation on branch fix-1792-corporate-proxy-podman. Summary below — I believe this
is enough to remove the spike label and move the issue toward review.

What the branch does

Supervisor (driver-agnostic core, openshell-supervisor-network):
The egress proxy now reads HTTPS_PROXY / HTTP_PROXY / ALL_PROXY / NO_PROXY from its
own environment, once at startup (the workload cannot influence it — its proxy variables
are still rewritten to point at the local policy proxy, unchanged). When policy approves an
outbound connection, the final TCP dial is chained through the corporate proxy with HTTP
CONNECT instead of dialing the destination directly. This covers all three dial sites:
CONNECT tunnels, plain HTTP forward requests, and the TLS-inspected relay (which wraps the
proxied socket exactly as it wrapped the direct one).

Podman driver propagation:
New operator config https_proxy / http_proxy / no_proxy on the Podman driver (TOML,
CLI flags, env), validated at startup and injected into sandbox containers as proxy
environment defaults; per-sandbox environment values override them. The mise run gateway
script also forwards OPENSHELL_SANDBOX_{HTTPS_PROXY,HTTP_PROXY,NO_PROXY} into the generated
[openshell.drivers.podman] section.

Answers to the spike's open questions

Upstream proxy configuration: standard proxy variables on the supervisor's environment;
only http:// proxy URLs are supported (https:// and SOCKS are ignored with a warning).
An OCSF ConfigStateChange event is emitted when chaining is enabled.
NO_PROXY matching: hostnames, domain suffixes (.corp.com, *.corp.com, corp.com
are equivalent), exact IPs, CIDRs, and *. Loopback and the trusted host gateway always
dial directly, so cluster/host-internal paths are unaffected.
Proxy credentials: Basic auth from URL userinfo, pre-encoded into the
Proxy-Authorization header; never logged (Debug impls redact it).
SSRF and DNS semantics: policy evaluation, local DNS resolution, and SSRF checks run
exactly as before — the corporate proxy only replaces the final dial. The CONNECT target
sent upstream is the client-requested hostname, so hostname-filtering proxies and
split-horizon DNS at the proxy keep working.
Tests: unit coverage for proxy URL parsing, NO_PROXY matching (domains, IPs, CIDRs,
wildcard, port qualifiers), scheme selection, and the CONNECT handshake (success, auth,
non-200, oversized/malformed responses, timeout) against an in-process mock proxy, plus
Podman config validation tests.

Scope note (Kubernetes)

This branch validates the flow end-to-end on the Podman driver. The supervisor-side fix
is driver-agnostic: on Kubernetes the supervisor reads the same variables from its container
environment, so the podTemplate env approach from the issue description is expected to
work — but K8s propagation hasn't been exercised in this branch and could be verified as a
follow-up.

Docs (docs/reference/gateway-config.mdx) and architecture/sandbox.md are updated in the
same branch.

Ask: please remove spike and, if the approach looks right, apply state:agent-ready
so the PR can proceed.

feat(sandbox,podman): chain sandbox egress through corporate HTTP proxy

feat(sandbox,podman): trust corporate CA for TLS to https:// proxies

feat(vm): support corporate HTTP forward proxy egress for microVM san…

This issue has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity. Comment or remove the state:stale label to keep it open.

@prakashmirji

@prakashmirji are the changes done related to corporate proxy covering your needs?

@feloy

@prakashmirji are the changes done related to corporate proxy covering your needs?

@feloy - proxy servers can be unauhenticated or secured. For the secured one, following are cases

If the server address uses https, we need option to pass custom CA ( not sure we need to handle insecure=true option)
option to pass basic auth credentials
do we need to think about token based authentication for proxy server. I have not seen.

If these need additional enhancements/spike, we can move the current implementation to review

@prakashmirji

@prakashmirji can you please have a look at #3447 which adds support for secured connection to proxy?

This issue has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity. Comment or remove the state:stale label to keep it open.

This should be available now. I am going to close but if there are gaps please open a new issue.

Navigation Menu

Repository navigation

Supervisor L7 proxy should support HTTP_PROXY/HTTPS_PROXY for corporate environments #1792

Problem Statement

Proposed Design

Alternatives Considered

Agent Investigation

Checklist

Triage Assessment

Summary

Investigation

Recommendation

Spike resolution: corporate proxy chaining implemented and validated on the Podman driver

What the branch does

Answers to the spike's open questions

Scope note (Kubernetes)

31 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Supervisor L7 proxy should support HTTP_PROXY/HTTPS_PROXY for corporate environments #1792

Description

Problem Statement

Proposed Design

Alternatives Considered

Agent Investigation

Checklist

Activity

TaylorMutch commented on Jun 10, 2026

Triage Assessment

Summary

Investigation

Recommendation

feloy commented on Jul 7, 2026

Spike resolution: corporate proxy chaining implemented and validated on the Podman driver

What the branch does

Answers to the spike's open questions

Scope note (Kubernetes)

31 remaining items

github-actions commented on Sep 16, 2026

feloy commented on Sep 16, 2026

prakashmirji commented on Sep 18, 2026

feloy commented on Sep 18, 2026

github-actions commented on Oct 2, 2026

johntmyers commented on Oct 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions