@@ -9,5 +9,4 @@ Clause-②: no
 Eight auth routes answer by re-dispatching a request to better-auth in-process: `POST /api/v1/auth/admin/remove-user`, `/admin/has-permission`, `/admin/sso/register`, `/admin/sso/register-saml`, `/admin/sso/request-domain-verification`, `/admin/sso/verify-domain`, `/send-verification-email` and `/sys-session/revoke`. `AuthManager.handleRequest` establishes the re-dispatched request's client address by the client-address trust rule: `X-Forwarded-For` (its first entry), then `X-Real-IP`, count only when the stack declares `server.trustProxy`, and otherwise the address is the connection's peer address. Each route handed `handleRequest` the request alone, without the connection it arrived on. Six of them also rebuild the request before re-dispatching it, and the rebuilt request did not carry the forwarding headers.
 
 - **Now.** Each route hands `handleRequest` the connection it was called on, as the main auth mount does. Each rebuilt request carries the incoming request's `X-Forwarded-For` and `X-Real-IP`. Without a declared trusted proxy, the re-dispatched request is judged on the connection's peer address, whatever those headers say. With `server.trustProxy` declared, it is judged on the forwarded client address, the same address as the request the route serves.
-- **For hosts.** `@objectstack/plugin-auth/client-address` exports `FORWARDED_CLIENT_ADDRESS_HEADERS`, the forwarding headers `resolveClientAddress` reads, in the order it reads them. A seam that builds a request of its own carries these headers by reading this list.
 - **Unchanged.** What each route accepts or refuses, and every answer it gives. `resolveClientAddress` decides exactly as before. The main auth mount, and the `allowed_ip_ranges` allow-list in front of every auth route, already judged on the connection.
@@ -0,0 +1,42 @@
+// Copyright (c) 2026 ObjectStack. Licensed under the Apache-2.0 license.
+
+/**
+ * The forwarding facts the client-address trust rule reads
+ * (`./client-address.ts`, ADR-0069 D5/D7), and the one way a request this
+ * plugin re-dispatches in-process carries them (#24877).
+ *
+ * INTERNAL. This module is not on the package's `exports` map, and neither the
+ * package root (`index.ts`) nor the published `./client-address` entry
+ * re-exports it: nothing outside this package reads the list.
+ *
+ * ⛔ Keep this module free of imports. The published `./client-address` entry
+ * — the lean entry the runtime loads without the better-auth family — imports
+ * the list from here, so a value import here would become a load-time
+ * dependency of every consumer of that entry.
+ */
+
+/**
+ * The forwarded headers the rule reads, in the order it believes them, and
+ * only when the deployment declares `server.trustProxy`: `X-Forwarded-For`
+ * (its leftmost entry), then `X-Real-IP`. Lower-cased, as every adapter
+ * delivers them. `resolveClientAddress` reads exactly this list.
+ */
+export const FORWARDED_CLIENT_ADDRESS_HEADERS: readonly string[] = Object.freeze(['x-forwarded-for', 'x-real-ip']);
+
+/**
+ * Carry the forwarding facts the rule reads ({@link FORWARDED_CLIENT_ADDRESS_HEADERS})
+ * from the request a bridge serves onto the request it re-dispatches, as the
+ * incoming request had them. `AuthManager.handleRequest` judges the
+ * re-dispatched request by the rule, so it is judged on the same facts as the
+ * request the bridge serves: the forwarded client address behind a declared
+ * `server.trustProxy`, the connection peer otherwise, when the rule ignores
+ * these headers. The bridges' header builders (`register-sso-provider.ts`,
+ * `send-verification-email.ts`, `sys-session-revoke.ts`) call this; none of
+ * them names a header itself.
+ */
+export function carryForwardedClientAddress(from: Headers, to: Headers): void {
+  for (const name of FORWARDED_CLIENT_ADDRESS_HEADERS) {
+    const value = from.get(name);
+    if (value !== null) to.set(name, value);
+  }
+}
@@ -38,19 +38,15 @@
  * `./client-address` subpath entry, like `./rate-limit-storage`, so the runtime
  * reaches it without loading the better-auth family (see `tsup.config.ts`).
  * ⛔ Keep this module free of imports: a value import here becomes a load-time
- * dependency of every consumer of the entry.
+ * dependency of every consumer of the entry. The one exception is the list of
+ * forwarded headers the rule reads, from `./client-address-forwarding.ts`,
+ * which is internal and itself import-free (#24877).
  */
 
-/**
- * The forwarded headers the rule reads, in the order it believes them, and
- * only when the deployment declares `server.trustProxy`: `X-Forwarded-For`
- * (its leftmost entry), then `X-Real-IP`. Lower-cased, as every adapter
- * delivers them. {@link resolveClientAddress} reads exactly this list, so a
- * seam that builds a request of its own from one it was handed — an
- * in-process re-dispatch — carries the facts the rule reads by iterating it,
- * never a hand-copied set of names (#24877).
- */
-export const FORWARDED_CLIENT_ADDRESS_HEADERS: readonly string[] = Object.freeze(['x-forwarded-for', 'x-real-ip']);
+// [#24877] The forwarded headers this rule reads, in the order it believes
+// them. The list lives in an internal module so the in-process re-dispatches
+// carry exactly these facts without the list being published on this entry.
+import { FORWARDED_CLIENT_ADDRESS_HEADERS } from './client-address-forwarding.js';
 
 /** The three facts the rule decides from. */
 export interface ClientAddressInput {
 
@@ -22,7 +22,7 @@
  * (per-environment runtime) — mirroring `runSetInitialPassword`.
  */
 
-import { FORWARDED_CLIENT_ADDRESS_HEADERS } from './client-address.js';
+import { carryForwardedClientAddress } from './client-address-forwarding.js';
 import { inProcessRedispatchUrl } from './in-process-redispatch.js';
 import { readJsonRequestBody } from './request-json-body.js';
 
@@ -422,22 +422,6 @@ function rewriteSsoAdminUrl(request: Request, fromSuffix: RegExp, toPath: string
   }
 }
 
-/**
- * [#24877] Carry the forwarding facts the client-address trust rule reads
- * (`FORWARDED_CLIENT_ADDRESS_HEADERS`) from the request a bridge serves onto
- * the request it re-dispatches, as the incoming request had them.
- * `AuthManager.handleRequest` judges the re-dispatched request by that rule,
- * so behind a declared `server.trustProxy` it reads the forwarded client
- * address the incoming request carried; without one the rule ignores these
- * headers and judges on the connection peer.
- */
-function carryForwardedClientAddress(from: Headers, to: Headers): void {
-  for (const name of FORWARDED_CLIENT_ADDRESS_HEADERS) {
-    const value = from.get(name);
-    if (value !== null) to.set(name, value);
-  }
-}
-
 /**
  * The headers every re-dispatch below carries: the caller's credential
  * (cookie / bearer), its `Origin` (or the request's own), and its forwarding
 
@@ -30,7 +30,7 @@
  */
 
 import type { AuthRequestHandler } from './register-sso-provider.js';
-import { FORWARDED_CLIENT_ADDRESS_HEADERS } from './client-address.js';
+import { carryForwardedClientAddress } from './client-address-forwarding.js';
 import { inProcessRedispatchUrl } from './in-process-redispatch.js';
 import { readJsonRequestBody } from './request-json-body.js';
 
@@ -43,21 +43,6 @@ export interface ResendVerificationEmailResult {
 
 const trimStr = (v: unknown): string => (typeof v === 'string' ? v.trim() : '');
 
-/**
- * [#24877] Carry the forwarding facts the client-address trust rule reads
- * (`FORWARDED_CLIENT_ADDRESS_HEADERS`) from the request this route serves onto
- * a request it re-dispatches, as the incoming request had them, so
- * `AuthManager.handleRequest` judges both on the same facts: the forwarded
- * client address behind a declared `server.trustProxy`, the connection peer
- * otherwise.
- */
-function carryForwardedClientAddress(from: Headers, to: Headers): void {
-  for (const name of FORWARDED_CLIENT_ADDRESS_HEADERS) {
-    const value = from.get(name);
-    if (value !== null) to.set(name, value);
-  }
-}
-
 /**
  * Resolve the caller's own email by re-dispatching a `/get-session` through the
  * same better-auth handler (best-effort). Returns `undefined` when there is no
 
@@ -70,7 +70,7 @@
 import { SystemObjectName } from '@objectstack/spec/system';
 import type { AuthSessionApi } from '@objectstack/spec/contracts';
 import { inProcessSessionReadInput } from '@objectstack/types';
-import { FORWARDED_CLIENT_ADDRESS_HEADERS } from './client-address.js';
+import { carryForwardedClientAddress } from './client-address-forwarding.js';
 import { inProcessRedispatchUrl } from './in-process-redispatch.js';
 import {
   PLATFORM_ADMIN_REFUSAL_MESSAGES,
@@ -209,21 +209,6 @@ export function sysSessionRevokeDepsFor(manager: SysSessionRevokeManager, basePa
   };
 }
 
-/**
- * [#24877] Carry the forwarding facts the client-address trust rule reads
- * (`FORWARDED_CLIENT_ADDRESS_HEADERS`) from the request this route serves onto
- * the request the owner lane re-dispatches, as the incoming request had them,
- * so `AuthManager.handleRequest` judges both on the same facts: the forwarded
- * client address behind a declared `server.trustProxy`, the connection peer
- * otherwise.
- */
-function carryForwardedClientAddress(from: Headers, to: Headers): void {
-  for (const name of FORWARDED_CLIENT_ADDRESS_HEADERS) {
-    const value = from.get(name);
-    if (value !== null) to.set(name, value);
-  }
-}
-
 /**
  * Owner lane: better-auth's `/revoke-session`, with the resolved token and the
  * caller's own credentials and forwarding facts. Only status and body come