Skip to content

fix(embed): honor proxy env for non-loopback endpoints - #130

Merged
Grivn merged 1 commit into
mnemon-dev:masterfrom
spacemolt-molty:fix/embed-proxy-env
Sep 12, 2026
Merged

fix(embed): honor proxy env for non-loopback endpoints#130
Grivn merged 1 commit into
mnemon-dev:masterfrom
spacemolt-molty:fix/embed-proxy-env

Conversation

@spacemolt-molty

Copy link
Copy Markdown
Contributor

What

The embedding client's http.Transport now resolves its proxy from the environment (HTTPS_PROXY/HTTP_PROXY/NO_PROXY) for non-loopback endpoints, and never uses a proxy for loopback endpoints.

Why

NewClientWithModel set Proxy: nil on the transport. The comment said "Bypass system proxy for localhost connections" — but Proxy: nil disables proxy env for every endpoint, not just localhost. Two consequences:

  1. Behind a credential gateway that injects auth at the proxy boundary (a transparent HTTPS_PROXY, as used by e.g. OneCLI-style agent gateways), remote OpenAI-compatible embedding providers become unreachable: the client bypasses the gateway and hits the provider directly, then fails with 401 because the API key only exists gateway-side.
  2. Local Ollama keeps working either way, so nothing caught this in local testing.

Routing by endpoint fixes both: loopback never proxied, remote endpoints follow standard env resolution (so gateways work), and corporate proxies stop breaking local setups in the opposite direction.

One subtlety: the loopback branch returns an explicit no-proxy resolver (func(*http.Request) (*url.URL, error) { return nil, nil }) rather than nil, because a nil Transport.Proxy panics when invoked.

Follow-up to #127 (same area, found while wiring up a Voyage AI backend behind a credential gateway).

Checklist

  • Deterministic tests pass (make test)
  • Relevant E2E/process/Docker boundaries pass (make test-integration, when affected)
  • New/changed behavior is covered by tests
  • Documentation updated (USAGE.md, DESIGN.md, or README) if applicable
  • User-facing release-note impact described in this PR, if applicable

The embedding client set Proxy: nil on its http.Transport — intended to
keep local Ollama instances off corporate proxies, but it also disabled
proxy env for every remote endpoint. Behind credential gateways that
inject auth at the proxy boundary (a transparent HTTPS_PROXY), remote
OpenAI-compatible providers became unreachable: the client bypassed the
gateway, then failed with 401 because the key only exists gateway-side.

Route by endpoint instead: loopback (localhost / 127.0.0.0/8 / ::1)
never uses a proxy; everything else resolves through the standard
HTTPS_PROXY/HTTP_PROXY/NO_PROXY environment. The loopback branch returns
an explicit no-proxy resolver rather than nil, which panics when the
Transport invokes it.
@Grivn
Grivn merged commit 6c371ec into mnemon-dev:master Sep 12, 2026
2 checks passed
362224222 pushed a commit to 362224222/mnemon that referenced this pull request Sep 12, 2026
Syncs 26 upstream commits (PR mnemon-dev#87-mnemon-dev#130) into the Windows/embed.yml fork line: readonly write hardening and SQLite URI normalization (v0.2.7), token-friendly brief retrieval, npm-managed distribution and `mnemon update`, and the embed proxy/probe fixes. Merged upstream/master rather than the v0.2.8 tag so the proxy fix ships with it, since this fork's default OpenAI endpoint is remote.

Conflict resolution keeps embed.yml as the sole embedding configuration source. Upstream's new embed tests inject config through EmbedConfigFile instead of MNEMON_EMBED_* env; without that rewrite four of them would have silently targeted the default SiliconFlow endpoint over the network. Docs keep the embed.yml wording while adopting upstream's retention table and the sharper --readonly description, and the reworked TestOpenAIEmbed restores the dimensions coverage upstream added.

Two Windows gaps are closed so the deterministic tier is meaningful here. TestCodexPrimeHook skips on Windows because its isolated PATH is built from symlinks that carry no .exe suffix, so no shim resolves; TestCodexUserPromptHook still runs. The Makefile drops the Unix-only test/mnemond suites under GOOS=windows, where naming them explicitly aborted with 'build constraints exclude all Go files'. Both packages were already red on the fork baseline; they stay in the tier on other platforms.

Validated: go build ./... and go vet ./... on windows and linux, GOOS=windows go vet ./..., and make test green with all 14 embed tests passing.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants