Module exec 

Running a project’s own toolchain: a fixed argv, in the workspace, bounded.

This is the module the 0.17.0 repositioning rests on. Until it existed the crate could edit a repository and could not build one, so “debug a production issue” or “fix a deployment” were not tasks a contract could express — there was no way to run npm install, go build, pytest, or make.

What is fixed and what is supplied

The opposite arrangement to git, and deliberately. There the module owns the whole argv and the model supplies only paths, because git has subcommands that fetch code and options that execute it, so the safe set is a closed one. Here the model supplies the whole argv, because the point is to run a command this crate has never heard of — and the boundary moves accordingly: it is the Policy, checked on the program and on the joined argv, that decides which of them may start.

What stays fixed is that there is no shell. The argv is an array of strings handed to the operating system as an array of strings, so ;, &&, $( ) and a backtick are ordinary bytes inside one argument rather than syntax. A command with a metacharacter in it does not become two commands, because nothing on this path ever parses one.

What this does not bound

A command runs in the workspace root with the embedding program’s privileges, not inside the Sandbox. That is the owner’s decision of 2026-07-29, recorded in US-IO-HARNESS-0.17.0-I02, and it is taken with its cost stated: the sandbox denies network egress by default and discards its working directory, which is right for a verification gate and makes npm install impossible. So the policy decides what may start, and not what a started process then does — the same honest bound this crate already states for a registered Tool and for a stdio MCP server.

Two ceilings apply to what a started process may do to the run: a wall-clock timeout, so a wedged command dies naming itself instead of consuming the contract’s whole time budget and reporting a budget stop; and the run’s own per-observation ceiling applied head-and-tail, so a build log keeps what ran at the top and what failed at the bottom.

Constants

DEFAULT_EXEC_TIMEOUT

How long a command started by the exec tool may run before it is killed.