Question
Deno Permissions Request in Headless CI: Need for a No-Prompt Flag?
Nia Vale
0 reputation · 28 Aug 2021, 02:42 UTC
12.2K views1
Loading…
0 reputation · 28 Aug 2021, 02:42 UTC
Deno's permission system requires explicit flags at startup, but also offers runtime requests via Deno.permissions.request(), which triggers a user prompt in interactive terminals.
In non‑interactive CI or Docker environments, the lack of a TTY causes the process to hang or fail because the prompt cannot be answered.
Current workarounds such as --allow-all or piping n to stdin are not officially recommended and compromise the security model.
An open question remains whether Deno will add a --no‑prompt flag that automatically denies runtime requests, or provide an API to pre‑declare dynamic permissions without user interaction.
Can a headless CI pipeline reliably run scripts that call Deno.permissions.request() without hanging? Which approach—pre‑declaring permissions via flags or a future --no‑prompt flag—best balances security and automation?
30275 reputation · 28 Aug 2021, 08:23 UTC
Yes – Deno ships a --no-prompt flag that suppresses all interactive permission prompts. In a CI or Docker pipeline you can run a script that calls Deno.permissions.request() without hanging:
denojsdeno run --no-prompt --allow-net --allow-read script.tsWhen the script invokes Deno.permissions.request(), the call will either succeed (if the permission is already granted via a flag) or fail with a PermissionDenied error. The flag does not automatically grant permissions; it merely removes the interactive safety gate.
--no-prompt, a non‑TTY environment blocks on the prompt and the job hangs.--no-prompt bypasses the runtime audit; the script must be fully pre‑declared.--allow‑… flags.deno --version. --no-prompt is available from 1.25 onward.read, net, env).--no-prompt:
deno run --no-prompt --allow-net --allow-read script.ts--allow‑… flag or refactor the code to avoid dynamic requests.Because --no-prompt removes the interactive audit, use it only in trusted CI environments:
--allow‑… flags over --allow-all.--allow-all vs --no-promptIf the repository is fully trusted and you want maximum automation, --allow-all is convenient but less secure. --no-prompt combined with specific --allow‑… flags offers a balanced approach: it prevents accidental permission escalation while still allowing unattended execution.
Does your script perform any dynamic permission requests that are not covered by the command‑line flags? If so, you’ll need to add the corresponding --allow‑… flag.
Use comments to ask for clarification. Post a solution as an answer.
30,275 reputation · 28 Aug 2021, 04:32 UTC
In a truly headless environment (no TTY), Deno.permissions.request() resolves immediately to { state: "denied" }. The process does not hang, and the --no-prompt flag is unnecessary.
If your CI system allocates a pseudo‑TTY (e.g., docker run -t or a job runner that forces a terminal), the request will attempt to show a prompt and can hang. In that case adding --no-prompt suppresses the interactive prompt and causes the request to deny automatically.