Terminal Downloads Work but VS Code Extensions Fail on VPN

curl works in the container and the extension still will not install. Compare the local editor and the remote environment before copying proxy settings.

Downloads that succeed in the container terminal are real evidence about that terminal's environment. They say nothing about the editor process, the extension installer, or the binary an extension fetches afterwards. Copying proxy variables between those three turns one failing request into an afternoon of unrelated edits.

Two environments usually differ in exactly one respect. Finding that respect is faster than reading the proxy documentation twice.

Which Process Made the Failed Request

Three requests can fail during a single install, and each has its own network identity. The editor asks the Marketplace for metadata and a package URL, then downloads the package. Only after that does the extension host run code that may fetch a language server or a binary of its own. Whichever stage broke decides which process needs a proxy, and the error surface rarely names the stage.

A working terminal proves the container can reach the internet, not that the editor can. Read the extension log for the last URL it attempted. The host named there identifies the process and the policy that applies to it.

Local Editor and Remote Container Are Two Environments

In a remote workspace an extension runs on the side its type declares. Interface extensions stay with the local editor, and workspace extensions run in the container. A proxy set in one is invisible to the other, and a rebuild recreates the container environment from its configuration file rather than from whatever you exported in a shell. That split explains why the same extension installs on a laptop and fails on the same project over SSH.

Read the installation location before editing anything. When the log reports a remote install, the container's environment is the one that matters.

Put the Proxy Where the Request Starts

For a Dev Container that genuinely needs an HTTP proxy, the variable belongs in the container configuration so a rebuild reproduces it. The fragment below sets it for that environment. The placeholder address stands in for your own gateway, and the exclusions are not optional padding.

"containerEnv": {
  "HTTP_PROXY": "http://proxy.corp.example:8080",
  "HTTPS_PROXY": "http://proxy.corp.example:8080",
  "NO_PROXY": "localhost,127.0.0.1,.internal.example"
}

The variable name describes the destination protocol, so an HTTPS_PROXY value may legitimately begin with http. Apply the change through the supported rebuild path, and keep the exclusions, because a proxy that intercepts internal hosts breaks services the container needs.

Separate Trust Failures From Reachability

A proxy that connects and then returns a certificate-verification error has reached a later stage than one that refuses the connection. The first failure wants the organization's approved trust material installed in the environment that performs the request. The second wants a reachable address and port. Treating them as one problem produces a fix that works for neither.

Disabling verification, or running the editor with elevated rights, is not a repair for a missing proxy or an absent trust chain. Both trade a visible error for a silent one. Retry the same extension afterwards and note the next URL that fails.

env | grep -iE '^(http|https|no)_proxy='
code --install-extension ms-python.python --force

Record which side of the workspace produced that URL. A short note naming the stage, the host and the side is worth more than a list of settings someone changed, because that note is what the next person can reproduce.

Qillqakuna t'inkisqa