[FEATURE]: Plugins can't intercept outbound requests for AI-SDK models (http.request hook excludes the AI-SDK path) #42846

Activity

1. github-actions

   assigned

   rekram1-node

   on Aug 16, 2026
2. github-actions commented on Aug 16, 2026

   

   github-actionsBot

   on Aug 16, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue doesn't fully meet our contributing guidelines.

   What needs to be fixed:

   • This issue does not use one of the required issue templates (Bug Report, Feature Request, or Question). Feature requests should use the Feature Request template and have a title starting with [FEATURE]:.

   Please edit this issue to address the above within 2 hours, or it will be automatically closed.

   If you believe this was flagged incorrectly, please let a maintainer know.
3. github-actions

   added

   needs:complianceThis means the issue will auto-close after 2 hours.This means the issue will auto-close after 2 hours.

   on Aug 16, 2026
4. BenSharir

   changed the title [-]Plugins can't intercept outbound requests for AI-SDK models (http.request hook excludes the AI-SDK path)[/-] [+][FEATURE]: Plugins can't intercept outbound requests for AI-SDK models (http.request hook excludes the AI-SDK path)[/+] on Aug 16, 2026
5. github-actions

   removed

   needs:complianceThis means the issue will auto-close after 2 hours.This means the issue will auto-close after 2 hours.

   on Aug 16, 2026
6. github-actions commented on Aug 16, 2026

   

   github-actionsBot

   on Aug 16, 2026 – with GitHub Actions

   Contributor

   More actions

   Thanks for updating the issue! It now meets the contributing guidelines. We appreciate the detailed write-up.
7. tespio commented on Oct 12, 2026

   

   tespio

   on Oct 12, 2026

   More actions

   Concrete instance of this gap, with a working implementation — because it is the same missing seam.

   The case

   A provider whose endpoint is reachable only through a corporate HTTP proxy, while every other
   provider connects directly:

   workstation --VPN--> [ proxy 192.168.10.101:3128 ] --LAN--> [ vLLM 192.168.10.86:5005 ]
           \------------------> public internet: reachable directly
   

   Probe	Result
   TCP connect to 192.168.10.86:5005 directly	connect timeout — no route
   TCP connect to 192.168.10.101:3128	reachable
   CONNECT 192.168.10.86:5005 via the proxy	HTTP/1.1 200 Connection established

   The direct route is absent, not misconfigured. Exactly one destination is gated, so routing must be
   scoped to one provider — which is the "scoped by target" requirement in this issue, not a separate
   feature request.

   Why the existing options do not cover it

   HTTP_PROXY works and is process-wide, so it applies to traffic that must not be proxied. The
   consequence is already tracked: #49796 is an open, reproduced issue where a process-wide proxy breaks
   OpenCode's own local client, because it dials http://0.0.0.0:<port> and the CLI does not rewrite
   that to loopback. A seam scoped by target cannot produce that failure. NO_PROXY can express "one
   destination", but not two providers behind two different proxies, and it applies to every tool in the
   process rather than to a request.

   There is currently no hook that can express this, which is the claim of this issue. What exists
   is a workaround, and it is worth reporting what it took, because all four points are properties of
   the AI-SDK path rather than of the plugin:

   What the workaround had to do

   opencode-fetch-proxy (npm, MIT) wraps the global fetch that AI SDK providers fall back to, and
   routes per provider. It works in daily use against the topology above, including SSE streaming. Four
   findings:

   1. undici's ProxyAgent is not reliably importable from where a plugin runs — in the desktop
      sidecar it does not resolve, and import { ProxyAgent } from "undici" then degrades to a direct
      connection. That is a silent failure: it presents as the proxy being unreachable. A hand-rolled
      CONNECT tunnel over node:net/node:tls (TLS negotiated inside the tunnel) is what actually
      carries traffic. A native seam should choose its transport by runtime detection, not assumption.
   2. Loopback must be refused unconditionally. A provider pointed at 127.0.0.1 with a proxy
      configured fails with 503 Service Unavailable, because the proxy has no route back to the
      workstation's loopback — the same class as cli: service configured with hostname 0.0.0.0 is unreachable when an HTTP proxy is set #49796, and it surfaces as a hang rather than an error.
   3. Model discovery is a separate request. GET /v1/models must be routed too, or the provider
      fails before the first completion. Any hook that only covers /chat/completions is insufficient.
   4. The global fetch patch is process-wide, so the workaround reproduces the scope problem it
      exists to solve, one level down. That is the strongest argument for the seam this issue asks for.

   The ask, restated from this use case

   An outbound-request seam on the AI-SDK path that exposes enough provider/baseURL context for a
   plugin to scope changes to one endpoint, with the ability to substitute the transport (not only
   mutate headers/body). Header/body rewriting alone would not cover proxy routing, because the
   connection itself has to go somewhere else.

   Happy to test a fix end-to-end against a live corporate proxy and a live LAN target — the topology is
   real and reproducible, and the workaround gives a reference implementation to compare against.
8. tespio commented on Oct 12, 2026

   

   tespio

   on Oct 12, 2026

   More actions

   Correction to the above: I described the implementation without linking it.

   • Source — https://github.com/tespio/opencode-fetch-proxy
   • Package — https://www.npmjs.com/package/opencode-fetch-proxy (npm i opencode-fetch-proxy, MIT)

   The code referenced above is in index.js at that repo. Pointers to the four findings, for anyone
   reading this later:

   • hand-rolled CONNECT tunnel, because undici's ProxyAgent does not resolve here —
     https://github.com/tespio/opencode-fetch-proxy/blob/main/index.js#L577
   • loopback refused before any other rule —
     https://github.com/tespio/opencode-fetch-proxy/blob/main/index.js#L375
   • per-provider options.proxy resolution —
     https://github.com/tespio/opencode-fetch-proxy/blob/main/index.js#L415

   It is a workaround, not a proposed design, and the fourth finding above is the reason: a global
   fetch patch cannot scope itself, which is what this issue asks to fix properly.
9. opencode-agent commented on Oct 13, 2026

   

   opencode-agentBot

   on Oct 13, 2026 – with OpenCode Agent

   Contributor

   More actions

   This is fixed on dev: #50487 made the session http.request/http.response hooks run on the AI SDK route too, and custom OpenAI-compatible providers (@ai-sdk/openai-compatible) now use the native route, where these hooks already applied. Plugins can inspect or replace outbound headers and bodies (redaction, compression, etc.) for both, scoped by providerID or the request URL.
10. opencode-agent

    closed this as completedon Oct 13, 2026
11. tespio commented on Oct 14, 2026

    

    tespio

    on Oct 14, 2026

    More actions

    Thanks — #50487 is the right fix for the header/body case, and routing custom
    @ai-sdk/openai-compatible providers through the native path is a real improvement.

    One question, so I know whether the proxy case is covered or out of scope.

    The note describes the seam as "inspect or replace outbound headers and bodies", with redaction and
    compression as the examples. Both are transformations of a request that is already going to the same
    place. A proxy changes where the connection goes — it is decided before any header exists, and for
    https the TLS session is established inside the tunnel to the proxy, not to the origin.

    Concretely, for this case the provider must be dialled through CONNECT 192.168.10.86:5005 at
    192.168.10.101:3128 rather than directly. Nothing in the request changes; the socket does.

    So: does the new seam allow substituting the transport/fetch (connection level), or only rewriting
    the request on the SDK's own fetch? If it is the former, this issue is genuinely closed and I will
    retire the workaround. If it is the latter, the gap is narrower than when I filed this and worth
    tracking separately as scope — not as a re-open.

    The reason I ask rather than assume: undici's ProxyAgent does not resolve where plugins run in
    the desktop sidecar, and it fails by silently connecting directly, which presents as the proxy
    being unreachable. Anything built on this seam for the proxy case needs the transport substitution to
    be explicit, or that failure mode comes back.

    Either way, happy to test on dev against the real topology and report back — a working reference
    implementation is linked in my earlier comment.
12. rekram1-node commented on Oct 14, 2026

    

    rekram1-node

    on Oct 14, 2026

    Last edited by rekram1-node

    Collaborator

    More actions

    Yep, you can actually do this with session.http.request and session.http.response without patching globalThis.fetch.

    Since both event.request and event.response are replaceable Web Request / Response objects, you have full control over what gets sent and what response stream gets handed back.

    Here's a basic example of how you could run your CONNECT tunnel in-memory without opening a local port, by turning the default fetch into a no-op data: request and swapping in your tunnelled response:

    const original = new WeakMap<Request, Request>()
    
    ctx.session.hook(
      "http.request",
      async (event) => {
        const noop = new Request("data:text/plain,")
        original.set(noop, event.request)
        event.request = noop
      },
      { providerID: "my-vllm" },
    )
    
    ctx.session.hook(
      "http.response",
      async (event) => {
        const req = original.get(event.request)
        if (!req) return
        event.response = await tunnelledFetch(req, proxyUrl)
      },
      { providerID: "my-vllm" },
    )
    Or if you prefer a single hook, you could rewrite event.request in http.request (or event.baseURL in model.request) to point at a local 127.0.0.1 forwarder in your plugin that tunnels to the proxy.
    That's just a rough sketch though. You can probably have your agent look at packages/core/src/session/model-request.ts, packages/core/src/aisdk.ts, and https://opencode.ai/v2/docs/build/plugins to figure out what's best for your setup.