Home / Use cases / A coding agent in CI
Continuous integrationA coding agent in CI
Run an agent step in CI without an npm install or pip install of a heavy runtime — an 8ms cold start and a 960KB binary, per the README.
The problem
Adding an AI agent step to CI usually means pulling a large runtime and its dependency tree on every job, or a Docker image, before the agent even starts. That fixed cost dominates short jobs and inflates cache sizes across a fleet of runners.
How tokenworm handles it
- ▸The tokenworm binary is a single native executable — install it with brew, npm, or pip, or drop the built binary onto the runner.
- ▸Per the README, cold start is 8ms and idle memory is 2.4MB, so the agent starts and finishes without a runtime warm-up tax.
- ▸The bash tool runs inside an OS-level sandbox (bubblewrap on Linux) so an agent step cannot escape the workspace.
- ▸Export a .tworm session from one CI step and resume it in another — the format is portable across surfaces.
# Provider key from CI secrets export ANTHROPIC_API_KEY="$SECRET" # One-shot task, sandboxed by default tokenworm --provider anthropic "summarize the diff in this PR" # Persist the trace for the build log tokenworm --trace-file trace.json "run the test suite and report failures"
- ·No hundred-megabyte dependency install and no Docker pull just to start the agent.
- ·All performance figures here are the README-reported numbers, run on Linux x86_64.
Questions
+ Is it safe to let the agent run shell commands in CI?
By default the bash tool runs in an OS-level sandbox — bubblewrap on Linux, sandbox-exec on macOS — and all tools are workspace-scoped. You can disable the sandbox with --no-sandbox if a runner requires it, but the default is isolated.
+ Can I pin a provider for reproducible CI runs?
Yes. Pass --provider on the CLI to select one of the five providers explicitly, and set the matching API key from CI secrets. Provider selection is a runtime flag, not a build-time choice.