Deno support as a security-conscious alternative to Node.js execution

[mokemoko]

Background

One concern I've heard from users — and felt myself — is hesitation around running a young, unfamiliar repository's code directly via npx or npm install -g. Tools that read local files and make network requests are exactly the kind of thing security-conscious developers pause over.

Deno addresses this directly. It runs TypeScript natively and requires explicit permission flags (--allow-read, --allow-net, etc.) at invocation time, so users can see and control exactly what the tool is allowed to do. No implicit trust required.

How much work is actually involved?

Less than you might think. The core change is adding node: prefixes to Node.js built-in imports:

// before
import { readFile } from 'fs/promises'
import { join } from 'path'

// after
import { readFile } from 'node:fs/promises'
import { join } from 'node:path'

Node.js has supported the node: prefix since v16, so this change is fully backwards-compatible — the existing build pipeline is unaffected.

On top of that, a deno.json with an import map for the npm dependencies (commander, chalk, ink, react) is enough to make deno run work.

I put together a rough proof-of-concept: mokemoko@5b59373

Note: This commit includes some noise — a deno.lock, a bundled litellm-pricing.json for offline use, and a few experimental extras that wouldn't land in a clean implementation. The relevant signal is in the src/ and deno.json changes.

What this would enable

With minimal permission flags, users could run codeburn with explicit, auditable control over what it can access:

deno run --allow-read --allow-env --allow-sys=homedir \
  https://raw.githubusercontent.com/AgentSeal/codeburn/main/src/cli.ts

Network access, write access, and subprocess execution become opt-in rather than implicit.

Question

Is this something worth pursuing? Happy to contribute a clean PR if there's appetite for it. Equally happy to hear if the added complexity isn't worth it for the target audience.

[AgentSeal]

Thanks for the thoughtful writeup and the PoC — appreciate the effort.

Two parts to this:

node: prefix migration — yes. This is good hygiene regardless of Deno. Backwards-compatible with Node 16+ and aligns with modern conventions. Happy to take a clean PR for just this change.

Full Deno runtime support — not right now. The security framing makes sense in the abstract, but CodeBurn's audience is Claude Code developers who are already running npx constantly. And the tool reads ~/.claude/ session data — if someone doesn't trust the package enough to install it, they're not pointing it at their AI session history either way. The bigger concern is that Ink (React for terminals) in Deno isn't battle-tested, and maintaining two runtimes adds ongoing cost we'd rather spend on features.

So: PR for the node: prefix change is welcome. We're not committing to Deno as a supported runtime for now, but if the community wants to maintain a Deno-compatible fork, that's totally fine.

Thanks again for raising this.