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.