[Workers] Document ctx.access limitations

src/content/docs/workers/configuration/cloudflare-access.mdx

@@ -253,7 +253,7 @@ For advanced policy configuration, such as multiple identity providers, device p
 
 ## Read authenticated user identity with ctx.access
 
-Every time Cloudflare Access authenticates a request, your Worker can read the signed-in user's identity — including email, groups, device posture, and [more identity fields](/cloudflare-one/access-controls/applications/http-apps/authorization-cookie/application-token/#user-identity) — directly through `ctx.access`. No extra configuration or JWT parsing required.
+When Cloudflare Access authenticates a request that directly invokes your Worker, the Worker can read the signed-in user's identity — including email, groups, device posture, and [more identity fields](/cloudflare-one/access-controls/applications/http-apps/authorization-cookie/application-token/#user-identity) — through `ctx.access`. No extra configuration or JWT parsing is required.
 
 Use this to personalize responses, enforce fine-grained permissions, or log activity per user.
 
@@ -278,6 +278,18 @@ export default {
 
 </TypeScriptExample>
 
+### `ctx.access` limitations
+
+:::note
+`ctx.access` applies only to the Worker invocation authenticated by Access. Cloudflare Access does not propagate `ctx.access` through [Service Binding](/workers/runtime-apis/bindings/service-bindings/) HTTP requests or remote procedure call (RPC) invocations. The downstream Worker does not receive the caller's Access context.
+
+If the caller instead sends a `fetch()` subrequest to an Access-protected hostname with valid [service token headers](/cloudflare-one/access-controls/service-credentials/service-tokens/) or a valid [`CF_Authorization` cookie](/cloudflare-one/access-controls/applications/http-apps/authorization-cookie/), Access evaluates the new request and creates a `ctx.access` object for the downstream Worker. This is a newly authenticated context, not context propagated from the caller.
+
+Workers with [Static Assets](/workers/static-assets/) execute behind an internal router Worker. Access still protects the application and its assets. However, the router does not pass `ctx.access` to the user Worker.
+
+The Cloudflare Vite plugin can add `assets` to the generated deployment configuration when the input Wrangler configuration omits it. Frameworks that use the plugin, including TanStack Start, can therefore be affected even when their source configuration does not declare Static Assets.
+:::
+
 ## Test ctx.access locally
 
 When developing locally with `wrangler dev` or the Cloudflare Vite Plugin, you can simulate authenticated Cloudflare Access identities without deploying or going through an Access login flow.

src/content/docs/workers/runtime-apis/bindings/service-bindings/index.mdx

@@ -62,6 +62,10 @@ Worker A that declares a Service binding to Worker B can call Worker B in two di
 1. [RPC](/workers/runtime-apis/bindings/service-bindings/rpc) lets you communicate between Workers using function calls that you define. For example, `await env.BINDING_NAME.myMethod(arg1)`. This is recommended for most use cases, and allows you to create your own internal APIs that your Worker makes available to other Workers.
 2. [HTTP](/workers/runtime-apis/bindings/service-bindings/http) lets you communicate between Workers by calling the [`fetch()` handler](/workers/runtime-apis/handlers/fetch) from other Workers, sending `Request` objects and receiving `Response` objects back. For example, `env.BINDING_NAME.fetch(request)`.
 
+:::note[Cloudflare Access context]
+Cloudflare Access does not propagate `ctx.access` from Worker A to Worker B. This applies to HTTP requests and RPC invocations. Do not treat the downstream invocation as authenticated by the caller's Access context. For more information, refer to [`ctx.access` limitations](/workers/configuration/cloudflare-access/#ctxaccess-limitations).
+:::
+
 ## Example — build your first Service binding using RPC
 
 This example [extends the `WorkerEntrypoint` class](/workers/runtime-apis/bindings/service-bindings/rpc/#the-workerentrypoint-class) to support RPC-based Service bindings.

src/content/docs/workers/static-assets/routing/worker-script.mdx

@@ -16,6 +16,12 @@ If an appropriate static asset if not found, Cloudflare will invoke your Worker
 
 This allows you to easily combine together these two features to create powerful applications (e.g. a [full-stack application](/workers/static-assets/routing/full-stack-application/), or a [Single Page Application (SPA)](/workers/static-assets/routing/single-page-application/) or [Static Site Generation (SSG) application](/workers/static-assets/routing/static-site-generation/) with an API).
 
+## Cloudflare Access context
+
+:::note
+When a Worker has Static Assets, the internal assets router does not pass `ctx.access` to the user Worker. Access still protects the Worker and its assets, but `ctx.access` is unavailable to the user Worker. For more information, refer to [`ctx.access` limitations](/workers/configuration/cloudflare-access/#ctxaccess-limitations).
+:::
+
 ## Run your Worker script first
 
 You can configure the [`assets.run_worker_first` setting](/workers/static-assets/binding/#run_worker_first) to control when your Worker script runs relative to static asset serving. This gives you more control over exactly how and when those assets are served and can be used to implement "middleware" for requests.

src/content/docs/workers/vite-plugin/reference/static-assets.mdx

@@ -26,6 +26,12 @@ On running `vite build`, an output `wrangler.json` configuration file is generat
 The `assets.directory` field in this file is automatically populated with the path to your `client` build output.
 It is therefore not necessary to provide the `assets.directory` field in your input Worker configuration.
 
+:::note[Cloudflare Access context]
+The Vite plugin can add Static Assets to the generated deployment configuration even when the input Wrangler configuration does not include `assets`. Workers with Static Assets do not receive `ctx.access` in the user Worker.
+
+This behavior affects frameworks that use the Cloudflare Vite plugin, including TanStack Start. For more information, refer to [`ctx.access` limitations](/workers/configuration/cloudflare-access/#ctxaccess-limitations).
+:::
+
 The `assets` configuration should be used, however, if you wish to set [routing configuration](/workers/static-assets/routing/) or enable the [assets binding](/workers/static-assets/binding/#binding).
 The following example configures the `not_found_handling` for a single-page application so that the fallback will always be the root `index.html` file.