Small updates to env docs

Author: mikenomitch

src/content/changelog/workers/2025-02-28-importable-env.mdx

@@ -1,9 +1,9 @@
 ---
-title: Import Env for direct access to bindings
-description: More easily configure your worker and call bindings from anywhere in your Worker with an importable `env`
+title: Import Env for direct access to bindings in your Worker code
+description: More easily configure your Worker and call bindings from anywhere with an importable `env`
 products:
   - workers
-date: 2025-03-04T11:00:00Z
+date: 2025-03-07T19:00:00Z
 ---
 
 import { Render, TypeScriptExample } from "~/components";
@@ -34,9 +34,14 @@ export default {
 ```
 
 :::note
-Workers error if attempting to perform I/O from outside a request context.
-This means that even though `env` is accessible from the top-level scope, not
-all bindings will work.
+Workers do not allow I/O from outside a request context. This means that even
+though `env` is accessible from the top-level scope, you will not be able to access
+every binding's methods.
+
+For instance, environment variables and secrets are accessible, and you are able to
+call `env.NAMESPACE.get` to get a [Durable Object stub](/durable-objects/api/stub/) in the
+top-level context. However, calling methods on the Durable Object stub, making [calls to a KV store](/kv/api/),
+and [calling to other Workers](/workers/runtime-apis/bindings/service-bindings) will not work.
 :::
 
 Additionally, `env` was normally accessed as a argument to a Worker's entrypoint handler,

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

@@ -127,9 +127,14 @@ export default {
 };
 ```
 
-Workers do not allow I/O outside of a request context. This means that certain bindings will
-not work from the top-level context. For instance, making a call to the [KV binding](/kv/concepts/kv-bindings/)
-will error, but making it from within a request will work.
+Workers do not allow I/O from outside a request context. This means that even
+though `env` is accessible from the top-level scope, you will not be able to access
+every binding's methods.
+
+For instance, environment variables and secrets are accessible, and you are able to
+call `env.NAMESPACE.get` to get a [Durable Object stub](/durable-objects/api/stub/) in the
+top-level context. However, calling methods on the Durable Object stub, making [calls to a KV store](/kv/api/),
+and [calling to other Workers](/workers/runtime-apis/bindings/service-bindings) will not work.
 
 ```js
 import { env } from "cloudflare:workers";
@@ -182,7 +187,7 @@ for dependency injection and testing.
 The `withEnv` function provides a mechanism for overriding values of `env`.
 
 Imagine a user has defined the [environment variable](/workers/configuration/environment-variables/)
-"NAME" to be "Alice" in their Wrangler configuration file and deployed a worker. By default, logging
+"NAME" to be "Alice" in their Wrangler configuration file and deployed a Worker. By default, logging
 `env.NAME` would print "Alice". Using the `withEnv` function, you can override the value of
 "NAME".