AI Coding Agent Harnesses: A Runtime Field Report

Executive summary #

The headline finding: "Does it run on Node?" has no single answer here. Two harnesses run on an external Node interpreter, one runs on Python, two are JavaScript compiled into a self-contained native binary, one is pure Rust, and one is a desktop app that runs Node and Rust at the same time. You own a complete cross-section of how 2026-era agent tools ship.

Five runtime strategies #

Every agent in this audit is some flavor of "JavaScript or Python or Rust talking to an API." What separates them is how the runtime is delivered to your disk. There are five distinct answers, and knowing which is which tells you the tool's startup speed, its install footprint, and what can break it.

How we fingerprinted each runtime #

None of these tools advertises its runtime. We read it off the binary itself. The method is three cheap checks, in order, and each one resolves a different class of program.

Step 1: the first line

A text launcher starts with a shebang that names its interpreter. This alone settles the interpreted cases.

head -1 "$(command -v <tool>)"
#!/usr/bin/env node    -> Node script
#!/usr/bin/env bash    -> wrapper, follow what it exec's
#!.../python3.14       -> Python script

Step 2: the file type

If there is no readable shebang, the file is compiled. file confirms it is a Mach-O executable, but Mach-O does not tell you the language. That needs step 3.

Step 3: embedded string markers

Compilers leave their fingerprints inside the binary as plain strings: standard-library paths, dependency registries, engine internals. Grepping for them is a reliable language test.

Gemini CLI #

Google's terminal agent. The cleanest example of strategy 1: a script whose shebang points straight at the Homebrew Node binary.

Because the shebang hard-codes the Homebrew Node path, this tool is directly exposed to your system Node. A brew upgrade node changes the interpreter under it.

pi #

An open coding agent by @mariozechner, installed as a global npm package. The binary on PATH is named pi, not pi-coding-agent, which is why a search by package name can miss it. npm registers the CLI under the bin field, which often differs from the package name.

The ~/.npm-global prefix is a user-level global install location, which is why pi resolves without sudo. The declared floor of Node 20.6 is the release that stabilized built-in .env loading.

hermes-agent #

The only Python agent in the set. The command on PATH is a tiny bash launcher whose only job is to isolate the environment and hand off to a Python virtualenv.

#!/usr/bin/env bash
unset PYTHONPATH          # scrub inherited config so the venv stays clean
unset PYTHONHOME
exec ".../.hermes/hermes-agent/venv/bin/hermes" "$@"

The unset PYTHONPATH and unset PYTHONHOME lines are the giveaway it is Python: a venv only stays isolated if no inherited variable redirects the interpreter to system packages. Using exec replaces the shell process rather than spawning a child, so Ctrl-C reaches the Python agent directly.

Claude Code #

JavaScript at the source, but it does not run on your Node. The binary is a self-contained native executable with a JavaScript engine baked in.

Those __jsc_* and __wtf_config sections are JavaScriptCore internals (WTF is WebKit's "Web Template Framework"), the signature of a Bun-compiled standalone binary. The practical upshot: Claude Code carries its own engine and does not depend on a separate node being present. Historically it shipped as an npm package that did run on system Node; the native binary is the newer, dependency-free distribution.

OpenCode #

Same strategy as Claude Code: TypeScript source compiled to a native binary, no external interpreter.

OpenCode and Claude Code both report as native Mach-O binaries, yet are JavaScript inside. This is the case that breaks the naive "compiled means systems language" assumption.

Grok CLI #

xAI's terminal agent, and the first genuinely non-JavaScript harness in the set. Same Mach-O file type as Claude Code, completely different innards: Rust machine code with no JS engine anywhere.

The Rust standard-library paths and crate names are embedded for panic and backtrace support. One detail worth noting: the crates were pulled from git.twitter.biz, xAI's internal Cargo registry, not the public crates.io. The binary was compiled inside xAI's own build infrastructure. The ~/.grok/bin/grok entry shows a 31-byte size in ls because it is a symlink; the multi-megabyte real binary lives under ~/.grok/bundled/.

Codex #

The most interesting install. Codex is not a terminal CLI at all. It is an Electron desktop app, and it runs two runtimes at once.

The .codex-global-state.json file is full of Electron fingerprints (electron-persisted-atom-state, electron-main-window-bounds) along with references to gpt-5.5, guardian and full-access permission modes, and bundled plugins for documents, spreadsheets, presentations, and browser-use. The bundled engine binary is Rust, but compiled on a public CI runner (/Users/runner/) from public crates.io, a different supply chain than Grok's internal registry.

So the Codex desktop shell genuinely runs on Node, by way of Electron. The part doing the coding work is the Rust child process it launches. The Node layer is the window; the Rust layer is the engine.

Node vs Python vs Rust: which is more efficient? #

The honest answer for this class of tool: it barely matters, because agent harnesses are network-bound, not CPU-bound. More than 95 percent of wall-clock time is spent waiting on the model's HTTP response. Whatever the runtime, it is idle on a socket. The model is the bottleneck, not the interpreter.

Where real differences do exist:

Bottom line. If you are optimizing for snappy startup and zero dependency hassle, the compiled-native harnesses (Claude Code, OpenCode, Grok, and Codex's Rust core) have the edge over the raw-Node and raw-Python ones. For the actual work of talking to a model, Node vs Python is a rounding error next to which model you point it at and how smartly it batches its calls.

Reproduce it yourself #

The full fingerprinting flow, runnable on any of these tools. Replace <tool> with the command name.

# 1. Where is it, and is it a script or a binary?
command -v <tool>
file "$(command -v <tool>)"
head -1 "$(command -v <tool>)"     # readable shebang means interpreted

# 2. If it's a wrapper, see what it really runs
cat "$(command -v <tool>)"

# 3. If it's a compiled binary, read the language markers
B="$(command -v <tool>)"
strings -n 6 "$B" | grep -iE "rustc|\.cargo|go build id|javascriptcore|wtf_config" | head

# 4. GUI app with no PATH entry? Look for a live state dir
ls -la ~/.<tool> 2>/dev/null
mdfind "kMDItemFSName == '<tool>' && kMDItemContentType == 'public.unix-executable'"

System facts at audit time

• Host Node: v26.0.0 at /opt/homebrew/bin/node (Homebrew).
• Platform: macOS (Darwin 25.5.0), Apple Silicon (arm64).
• pi version: 0.70.5. hermes Python: 3.14. Codex model seen in state: gpt-5.5.