Does Deno.env.toObject() not support partial environment variable access?

[alex-deev]

Version

Deno 2.7.12

Repro Code

index.ts:

console.log(Deno.env.toObject());

Run with:

deno run --allow-env=PWD index.ts

Or replace PWD with other valid env var.

Actual Result

Permission system requests wide environment variable access.

┏ ⚠️  Deno requests env access.
┠─ To see a stack trace for this prompt, set the DENO_TRACE_PERMISSIONS environmental variable.
┠─ Learn more at: https://docs.deno.com/go/--allow-env
┠─ Run again with --allow-env to bypass this prompt.
┗ Allow? [y/n/A] (y = yes, allow; n = no, deny; A = allow all env permissions) > 

Expected Result

Deno just reads the allowed environment variables, permission system does not request for more.

[Object: null prototype] { PWD: "/project/workspace" }

Notes

The official Deno blog post for Deno 2.6 shows a similar example:

$ SOME_SECRET=foo deno run --allow-env=SOME_SECRET main.ts
{ SOME_SECRET: "foo" }

Did I misunderstood or missed something? Is that an expected behavior?

[felipeinf]

this looks like expected behavior tbh. Deno.env.toObject() needs to read all env vars to build the object, so --allow-env=PWD isn't enough — it only grants access to that one var.
If you just need PWD:

console.log(Deno.env.get("PWD"));

the blog post is a different story — it clearly shows toObject() working with --allow-env=SOME_SECRET and returning a filtered object. So either that was the actual behavior back in 2.6 and something changed, or the blog post is just wrong. Might be worth opening a separate docs issue for that

[everton-dgn]

Building on @felipeinf's answer about the blog post being off: I'm fairly sure the apparent filtering in the 2.6 post is a side effect of how the example is launched, not a real permission narrowing.

That example invokes the script with a shell prefix like SOME_SECRET=foo deno run .... The shell sets that one variable in the child process before deno starts, so the real process env the script inherits only has that variable plus whatever Deno/libc seed it with. When the script calls toObject(), the enumeration returns what looks like a filtered result, but it's actually enumerating the full (very small) environment. Run the same code from a normal shell where PATH, HOME, SHELL etc. are all inherited, and toObject() demands broad --allow-env again.

So the permission model is consistent: Deno.env.toObject() needs unrestricted --allow-env because enumeration is itself the side effect. A granular --allow-env=PWD never gates toObject, and there's no way for it to, since it'd have to read every var name to know which ones to filter.

For one-off access:

const pwd = Deno.env.get("PWD"); // works with --allow-env=PWD

Worth opening a docs issue on the 2.6 post so the example is clearer about what the shell prefix is doing vs what the permission is doing.

[x-tahosin]

This is a reported regression / behavior change in Deno 2.7.x, not user error. The Deno blog post you referenced uses an older permission prompt format; in recent versions, --allow-env=VAR grants read access to VAR specifically, but Deno.env.toObject() is implemented as a bulk read that enumerates all environment variables under the hood.

The technical reason

Deno.env.toObject() internally calls Deno.core.ops.op_env() (or equivalent), which does an environ() system call. This syscall returns the entire environment block, not individual variables. The Deno permission system sees this as a request to access the full environment namespace, hence the wide permission prompt.

This is different from Deno.env.get("PWD"), which resolves a single variable and the permission system can match it against your --allow-env=PWD grant.

What you're seeing vs. what the blog promised

The blog example from Deno 2.6:

$ SOME_SECRET=foo deno run --allow-env=SOME_SECRET main.ts
{ SOME_SECRET: "foo" }

This worked because toObject() was filtered at the JS layer in that version: it called the bulk API but then iterated and only exposed the keys matching the permission allowlist. In 2.7.x, the filtering moved or the permission check happens before the JS layer sees data.

Workaround: iterate the allowlist manually

If you need toObject()-like behavior with fine-grained permissions, build the object yourself from your known allowlist:

const ALLOWED = ["PWD", "HOME", "USER"] as const;

function envToObject(): Record<string, string> {
  const env: Record<string, string> = {};
  for (const key of ALLOWED) {
    const val = Deno.env.get(key);
    if (val !== undefined) env[key] = val;
  }
  return env;
}

console.log(envToObject());

Run with:

deno run --allow-env=PWD,HOME,USER main.ts

This never triggers the wide permission prompt because each Deno.env.get() is individually authorized.

If you really need the full toObject() with partial permissions

There isn't a clean way today. Two options:

1. Grant --allow-env broadly (less secure, but works):

   deno run --allow-env main.ts

2. File a Deno issue — this is a legitimate ergonomic regression. The expectation that --allow-env=VAR + toObject() returns only { VAR: value } is reasonable, and Deno core team has discussed it before.

Checking your exact Deno version

Run:

deno --version

If you're on 2.7.12 specifically, this behavior is known. If you're on 2.8+, check the Deno changelog — there was talk of reintroducing JS-layer filtering for toObject().

Recommended path

For now, avoid Deno.env.toObject() in scripts that run with fine-grained --allow-env. Use the explicit allowlist pattern above. It's more maintainable and self-documenting anyway — future readers of your code can see exactly which env vars the module depends on.

If this is blocking a library you're building (where you don't control the CLI flags), consider accepting an env object as a parameter and defaulting to Deno.env only in a compatibility layer:

export function myLib(options?: { env?: Record<string, string> }) {
  const env = options?.env ?? Deno.env.toObject();
  // ...
}

This lets callers pass envToObject() or a mock object in tests.

Does the explicit allowlist approach unblock you, or do you need true dynamic enumeration of only-granted variables?

[chrisjcthomas]

Deno.env.toObject() is designed to read and return the entire process environment block as a single key-value object. Because it retrieves all environment variables at once, it requires broad, unrestricted access to the environment.

When you run Deno with a scoped permission like --allow-env=PWD, Deno is strictly forbidden from reading any variables other than PWD. When Deno.env.toObject() is called, Deno tries to compile the full environment object, finds that it is not permitted to access all environment variables, and falls back to prompting the user for wide access.

How to resolve:

1. Explicit reads: If you only need access to a specific allowed variable (or a set of allowed variables), you should access them individually using Deno.env.get():

   console.log(Deno.env.get("PWD")); // Works without prompts when run with --allow-env=PWD

2. Granular extraction helper: If you want an object of allowed keys, you can manually build it using a predefined list of allowed variables:

   const ALLOWED_KEYS = ["PWD", "HOME", "USER"];
   const env: Record<string, string> = {};
   for (const key of ALLOWED_KEYS) {
     const value = Deno.env.get(key);
     if (value !== undefined) {
       env[key] = value;
     }
   }
   console.log(env); // Does not request additional permissions

3. If you must use .toObject(): You must grant full environment permissions using the bare --allow-env flag:

   deno run --allow-env index.ts

[hermannsorgel]

Since I've been messing with it a ton recently, here's what I found works:

"permissions": {
    "default": {
      "env": {
        "allow": ["PWD", "NAPI_RS_NATIVE_LIBRARY_PATH"],
        "deny": ["*"]
      }
    },
},

user: deno -P test.js
Warning Permissions in the config file is an experimental feature and may change in the future.
[Object: null prototype] {
  PWD: "/Users/user/testing"
}