openai/tunnel-client v0.0.20 on GitHub

OAuth forwarding across separate HTTPS origins

This release adds an independent allowlist for forwarding to discovered OAuth endpoints on separate HTTPS origins. Configure it with the repeatable --harpoon.oauth-forward-origin flag, the newline-separated HARPOON_OAUTH_FORWARD_ORIGINS environment variable, or harpoon.oauth_forward_origins in YAML. It is available in the full client and both runtime flavors.

For example, when your deployment discovers OAuth metadata and endpoints at https://auth.example.com:

mcp:
  oauth_trusted_origins:
    - https://auth.example.com
harpoon:
  oauth_forward_origins:
    - https://auth.example.com

Discovery trust and forwarding approval are separate settings. Include the protected-resource metadata source's origin and each required authorization-server endpoint origin. Entries must be HTTPS origins, without credentials, paths other than an optional /, queries, fragments, or IPv6 zone identifiers. Matching is exact by scheme, hostname, and effective port; it does not include subdomains or other ports. Flags replace the environment or YAML list, and the environment replaces YAML; explicit empty flag or environment values clear lower-precedence entries.

The allowlist defaults to empty, preserving existing behavior. It admits discovered OAuth endpoints while retaining their OAuth roles and groups; it does not register arbitrary URLs, grant discovery trust, widen configured credential scope, or relax redirect and exact-target checks. Generic Harpoon targets do not replace discovery-generated OAuth registrations. See the configuration reference.

Reliability and diagnostics

OAuth startup discovery now keeps retrying a candidate that times out even when another candidate returns HTTP 404. Readiness remains pending while retryable discovery recovers; permanent errors such as untrusted origins still fail discovery.
MCP startup probes that reach a server requiring authentication now log that expected condition at INFO level instead of reporting a connection error or compatibility warning.

Upgrade and downgrade guidance

Upgrade every active poller for a tunnel and apply equivalent forwarding configuration before relying on separate OAuth origins. Any poller may consume a command; setting the new environment variable on an older binary does not add this capability. Compare startup target counts and catalog digests only for replicas using the same tunnel ID and runtime key, then validate discovery, sign-in, and an authenticated MCP call.

Older binaries reject the new flag and YAML key. Remove those settings before downgrading; downgrading removes the explicit forwarding capability. Deployments leaving the new allowlist empty retain the existing forwarding policy.

Full changelog: v0.0.19...v0.0.20