The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A --no-run or --dry-run flag is not proof that a command-line tool will avoid launching an agent. To make a defensible claim, check the exact version’s documented contract and code path, then trace the exact invocation at runtime. State the limits: the result applies only to the binary, arguments, configuration, environment, and operating system you tested. A local process trace alone cannot rule out an agent started remotely through a service or daemon.
Why the flag name is not enough
CLI behavior is specific to each tool and version. OpenClaw documents openclaw agent exec as running an embedded agent turn, with behavior affected by configuration and runtime selection. The example shows why a command’s name or apparent purpose cannot establish whether it launches an agent. OpenClaw’s agent command documentation describes that behavior.
Other projects make narrower, explicit promises. The delegate-agent dry-run documentation says it builds a request and child arguments but does not launch a child runtime, create a registry run, branch, or worktree. WeKnora describes its dry-run as offline, with no SDK calls, client initialization, network queries, or file writes. Those are tool-specific contracts, not a shared definition of --dry-run. The delegate-agent dry-run documentation and WeKnora’s project documentation provide the respective claims.
Also distinguish an agent turn from shell execution. agent-compose documents run --prompt as sending a prompt to an agent provider, while run --command executes a shell command through its sandbox runtime; it documents exec as a command execution path as well. Trace the specific invocation rather than treating every command-execution path as an agent launch—or assuming it cannot launch one. agent-compose’s project documentation describes these paths.
#1 Best Overall
How to check a specific CLI
- Pin down what you are testing. Record the binary path, version or build hash, complete arguments, relevant configuration, environment, and operating system. When reviewing implementation, use the source revision corresponding to that release rather than assuming the current main branch matches it.
- Follow the dispatch path. Inspect how the CLI parses the exact arguments and which branch they select. Follow that branch into any child process, provider, API, or daemon call. Treat help text, documentation, and the flag name as claims to verify against the implementation, not as runtime observations.
- Trace process activity. On Linux, run the exact invocation under process lifecycle tracing. For example:
strace -f -e trace=%process -o trace.log -- /path/to/cli ...The
strace(1)manual describes the tool as tracing system calls and signals, and its process tracing can show process creation and execution. Inspect successfulexecveandexecveatcalls, as well as child process creation, to determine whether the CLI launched an agent or a runtime capable of launching one. Theexecve(2)manual definesexecveas executing a program. See the strace(1) manual and execve(2) manual. - Keep the evidence reproducible. Preserve the trace alongside the exact command and test conditions. Exercise relevant configurations and failure paths too; one successful run establishes evidence only about that invocation.
- Check beyond the local process tree. If the CLI can contact a daemon or service, review network activity and service-side audit evidence. A local trace cannot establish that a remote service did not start an agent.
What the trace can—and cannot—prove
A trace supports a bounded statement, for example: “For binary version X, with arguments Y and configuration Z on Linux, this observed invocation showed no traced child-agent execution.” It does not establish that the CLI can never execute an agent under other inputs or conditions. The conclusion also depends on what the trace captured: filtered system-call output may omit calls outside the selected set. The strace(1) manual documents the tracing interface and its scope.
Source review and runtime tracing answer different questions. Reviewing the parser and dispatch path shows what the implementation is designed to do for the arguments examined. Tracing shows what happened during a particular run. Neither alone establishes the behavior of every release, configuration, platform, or remote service.
Recommended Free Tools
Compare no-run claims using the same checks
| Evidence to compare | Question to ask |
|---|---|
| Documented contract | Does the documentation explicitly say that the mode forbids launching a child process or runtime? |
| Source dispatch | Does the tested argument path confirm that the implementation follows the documented no-launch behavior? |
| Runtime trace | Does the observed process activity show process creation or program execution? |
| Test scope | Which binary version, arguments, configuration, environment, and platform does the evidence cover? |
| Remote activity | Could the CLI ask a daemon or service to start an agent, requiring separate network or service-side audit evidence? |
Keep the conclusion tied to the release
Project documentation can change, and pages on a main branch may not describe an older installed release. Recheck the release being evaluated and match source review to its pinned revision. On operating systems other than Linux, use an appropriate process monitor; the example above is specifically for Linux strace.
Quick Recap
Rank #3
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
