A plugin serving an RPC endpoint cannot see the request that called it

[yuzisama224]

Host-side RPC dispatch drops the HTTP request before user code runs, so a plugin serving an endpoint has no way to learn anything the deployment's reverse proxy put on that request.

Where it stops

Headers reach DSH and are consumed by the trust and authentication layers through ConnectionTrustRequest (packages/client/connection/src/rpc.ts:80-81). They stop there. The handler contract is

export type ConnectionRpcHandler = (
  endpoint: string,
  payload: unknown,
  signal: AbortSignal,
) => Promise<ConnectionRpcResult<unknown>>

(packages/client/connection/src/rpc.ts:100-104) — no request, no headers. At the single dispatch site, packages/client/connection/src/rpc-host.ts:240, the Request is in scope as the enclosing fetch(request: Request) parameter (:208):

const result = await handler(endpoint, message.payload, request.signal)

The request is right there, used on that very line for request.signal, and everything else about it is dropped.

All references are to dsh-v0.1.2-rc.1 (a66e470).

Why this matters outside a single-user install

DSH's authentication model authenticates a browser to a process: the launch token and the browser session say this browser may talk to this process, not who is talking. That is the right model for the install DSH is built for.

We run DSH behind an authenticating reverse proxy, where more than one person reaches the same process and the proxy stamps the authenticated end user onto every request it forwards (X-Forwarded-User, oauth2-proxy's default). The proxy is the only network path to the process. Everything we want to build on top — showing a person their own sessions and not their colleagues', deciding who may act on a given session — needs that one string to reach a plugin. Today it structurally cannot.

We are not asking DSH to authenticate anyone, and not asking it to trust a header. We are asking for the request to still be readable at the point where a plugin runs. Whether a given header on it means anything is the deployment's problem, and stays the deployment's problem.

What we could not make work without a change

• Read it from the payload. The client would have to send it, which makes it a claim by the caller rather than a fact from the proxy — worthless for the purpose.
• A ctx key or a Cordis service. ctx is per-plugin, not per-request; two concurrent calls from two people share it.
• An exact Fetch route (ConnectionFetchRoute) does get the request, but it is outside Remote dispatch, so it buys nothing for the endpoints that matter.
• An interceptor. connection.rpc.intercept receives the same three arguments as a handler.

The change we would propose

One AsyncLocalStorage owned by client-connection, entered around the existing handler call, and one exported reader:

export function currentConnectionRequest(): ConnectionTrustRequest | undefined

ConnectionTrustRequest already exists and is already exported, so the reader adds no new type. It is undefined outside a dispatch, which makes the failure mode "no request in scope" rather than a wrong answer.

HostConnectionHandle also gains runWithRequest(request, dispatch), implemented by HostConnectionService, so a transport other than the /api HTTP route can enter the same scope and an endpoint owner reads one request context whatever carried the call. It is declared on the interface rather than only on the class because ctx.connection is typed as the interface, which is how any other package would reach it. api-gateway's WebSocket path is the one that needs it, and it is the subject of a companion post (#5791); that half is only worth discussing if this half has appetite.

The diff is three files and about 40 lines, most of it documentation. It touches no schema, no envelope, no trust check, and no part of the token exchange. It is attached or linked below.

Two things worth flagging.

Every /api dispatch now enters the scope, including the calls that never read it: the wrap is unconditional at the dispatch site, because a handler that wants the request cannot be distinguished from one that does not before it runs. AsyncLocalStorage.run is cheap relative to a JSON round trip, but we have not measured it against unary RPC latency in this repository and are happy to, if a number would help the decision.

AsyncLocalStorage is already the mechanism used for same-process attribution here. dsh-agent keeps two of them to carry the live Agent through the driver work it starts (packages/core/agent/src/index.ts:252-253, described as the initiator scope in packages/core/agent/README.md). This proposal is the same idea one layer out, at the transport edge instead of inside the agent loop. If you would rather not add a second such scope, an explicit fourth handler argument would also solve the problem, at the cost of a breaking change to ConnectionRpcHandler.

What we are asking

Is there appetite for per-request context at this seam? Specifically:

1. Is "a plugin can read the request it is serving" something DSH wants to offer at all, or is it out of scope by design?
2. If yes, is an AsyncLocalStorage scope the shape you would want, or would you rather widen the handler signature?
3. Should the scope be owned by client-connection, as proposed, or somewhere else?

We run the change as a local patch over the published 0.1.2-rc.1 package today, so this is not speculative and we are not blocked on an answer. We would rather not carry a patch, and we are happy to do the work in whatever shape you would accept — or to hear that you would not, which is also a useful answer.

diff --git a/packages/client/connection/src/index.ts b/packages/client/connection/src/index.ts
index 34cf79bd65..5a1022f834 100644
--- a/packages/client/connection/src/index.ts
+++ b/packages/client/connection/src/index.ts
@@ -39,7 +39,7 @@ export {
   rpcResultSchema,
   serverResponseSchema,
 } from './rpc-schema.ts'
-export { HostConnectionService } from './rpc-host.ts'
+export { currentConnectionRequest, HostConnectionService } from './rpc-host.ts'
 
 export { API_PATH } from './api-path.ts'
 
diff --git a/packages/client/connection/src/rpc-host.ts b/packages/client/connection/src/rpc-host.ts
index a9bbc72954..64bcdad34b 100644
--- a/packages/client/connection/src/rpc-host.ts
+++ b/packages/client/connection/src/rpc-host.ts
@@ -1,5 +1,6 @@
 /** Host registry and HTTP adapter for generic Connection RPC channels. */
 
+import { AsyncLocalStorage } from 'node:async_hooks'
 import { Context, Service } from '@deepseek-ai/cordis'
 import type { WebRoute } from '@deepseek-ai/dsh-host-webserver'
 import {
@@ -32,6 +33,24 @@ const INVALID_REQUEST_RPC_ID = RpcId('invalid-request')
 const CHANNEL_PATTERN = /^\/[A-Za-z0-9._~-]+$/
 const ENDPOINT_SEGMENT_PATTERN = /^[A-Za-z0-9_$.-]+$/
 
+const requestScope = new AsyncLocalStorage<ConnectionTrustRequest>()
+
+/**
+ * Read the request currently being dispatched on this async context.
+ *
+ * Connection decodes the transport envelope and then calls a
+ * `ConnectionRpcHandler`, which takes no request and no headers, so an endpoint
+ * owner cannot otherwise see what a deployment's reverse proxy put on the
+ * request. Available for the whole of a handler call, including after an
+ * `await`, and to anything the handler synchronously causes; `undefined`
+ * everywhere else. Headers are transport facts, not authenticated claims: only
+ * a deployment that controls the path to this process may treat one as trusted.
+ * @returns request facts of the active dispatch, or undefined outside one.
+ */
+export function currentConnectionRequest(): ConnectionTrustRequest | undefined {
+  return requestScope.getStore()
+}
+
 interface ConnectionRpcInterceptor {
   readonly matches: ConnectionRpcEndpointMatcher
   readonly fetchHandler: FetchHandler
@@ -98,6 +117,10 @@ export class HostConnectionService extends Service implements HostConnectionHand
     return this.browserAuth.isAuthenticated(request) ? undefined : 401
   }
 
+  runWithRequest<T>(request: ConnectionTrustRequest, dispatch: () => T): T {
+    return requestScope.run(request, dispatch)
+  }
+
   /** Authenticate an index request through the process-token exchange or cookie. */
   authorizeIndex(request: ConnectionIndexRequest, response: ConnectionIndexResponse): boolean {
     return this.browserAuth.authorizeIndex(request, response)
@@ -237,7 +260,10 @@ function rpcFetchHandler(
       }
 
       try {
-        const result = await handler(endpoint, message.payload, request.signal)
+        const result = await requestScope.run(
+          request,
+          () => handler(endpoint, message.payload, request.signal),
+        )
         return fullResponse(message.rpcId, result)
       } catch (error) {
         return new Response(`handler failure: ${String(error)}`, { status: 500 })
diff --git a/packages/client/connection/src/rpc.ts b/packages/client/connection/src/rpc.ts
index 12c8f198be..aadd2047bc 100644
--- a/packages/client/connection/src/rpc.ts
+++ b/packages/client/connection/src/rpc.ts
@@ -178,6 +178,17 @@ export interface HostConnectionHandle {
    */
   requestRejection(request: ConnectionTrustRequest): ConnectionRequestRejection
 
+  /**
+   * Run one dispatch inside the scope `currentConnectionRequest()` reads.
+   * Transports other than the `/api` HTTP route enter the same scope through
+   * this method, so an endpoint owner reads one request context whatever
+   * carried the call.
+   * @param request - request facts to publish for the duration of `dispatch`.
+   * @param dispatch - work to run inside the scope.
+   * @returns whatever `dispatch` returned.
+   */
+  runWithRequest<T>(request: ConnectionTrustRequest, dispatch: () => T): T
+
   /**
    * Authenticate one frontend index request, owning a token redirect or 401.
    * @param request - root or configured-index HTTP request.

[argszero]

First responder note — this thread is the consumer/read-side leg of a seam this repository has already engaged three times on the enforcement side, so the family history is directly relevant to your "is there appetite?" question:

• Privileged RPCs behind a reverse proxy: accept verified proxy identity (Tailscale-User-Login) as operator equivalence — and a Host-passthrough finding #3210 — privileged RPCs spoofable behind Host-preserving proxies; outcome direction: opt-in privilegedIdentityLogins allowlist keyed on proxy-attested identity (Tailscale-User-Login), empty default, hard precondition on non-loopback bind. That thread established the doctrine your post restates correctly: a proxy-stamped header is a transport fact, and only a deployment that controls the path to the process may treat it as trusted.
• 希望为特权 API 方法增加 privilegedTrustedHosts 配置项 #3459 — same axis from the reachability side (privilegedTrustedHosts behind oauth2-proxy); the maintainer-side pattern is consistently "additive opt-in, empty-default fail-closed".
• Six implementation findings with fix proposals (0.1.1-rc.2, Windows) #5198 finding ⑤ — the converse gap on the same seam: cordis-host-runner's dynamic-plugin invoke RPC threads no session context at all into the Host handler invocation (pluginRunId currency only), where sibling remote paths do (sessionId: request.sessionId + ownership validation). Worth citing because it shows the seam is already expected to carry per-request attribution, and it is currently incomplete in both directions: the dispatch drops the request (your A plugin serving an RPC endpoint cannot see the request that called it #5790/WebSocket-dispatched Remote invocations carry no request context #5791) and one invoke path drops the session (Six implementation findings with fix proposals (0.1.1-rc.2, Windows) #5198-f5).

On the shape: your AsyncLocalStorage proposal is the right mechanism here — you found the in-tree precedent yourself (dsh-agent initiator scope at packages/core/agent/src/index.ts:252-253), and it composes: a store owned by client-connection that currently carries the ConnectionTrustRequest is also the natural future carrier for a session id, which is exactly the field #5198-f5 found missing. An explicit fourth handler argument would force every endpoint owner to care about a scope most never read; the ALS reader keeps it opt-in without widening the contract.

One expectation to set: your deployment (multi-person behind an authenticating proxy) will keep surfacing dsh's single-user assumptions beyond the request context — per-user session listing/ownership is the next one you will hit (sessions are single-writer and process-local in ownership today). A request scope at this seam is the foundation those would all build on, which is an argument for getting the primitive right rather than solving each consumer one at a time.