> For the complete documentation index, see [llms.txt](https://docs.talus.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.talus.network/reference/cli/execution.md). # nexus execution **Audience:** Nexus CLI users and integrators. **Command:** `nexus execution`. **Generated from:** Nexus CLI `v2.1.1` release executable at commit `08bfe76e726922ce512d623fbc1d2e1bd786bcd4` (generated inventory preserved below). This page is the complete help tree for `nexus execution`. Global output flags can appear after the family or nested subcommand. ### Invocation authorization contract The CLI exposes `nexus execution authorize` to select one accepted Invocation policy for an active runtime vertex: fixed price, finite credits, time pass, or a custom policy with explicitly typed arguments. The command returns the exact Invocation and lock identity; it does not accept a cashier candidate as a substitute. Timeout/refund operations likewise use the exact `invocation_id` before applying workflow abort or Task occurrence settlement. Verify matching `--help` output, network objects, package IDs, and transaction effects before running it. Confirm the selected binary’s clap/help output and the resulting `InvocationLocked` transaction event before relying on an exact command or receipt in a deployment. The custom form requires a qualified policy witness and preserves argument order: `nexus execution authorize --execution-id 0x42 --leader-cap 0x43 --walk-index 0 --vertex worker custom --policy 0xabc::my_policy::Policy --argument object:0x10 --argument mutable:0x11 --argument id:0x12 --argument pure:deadbeef`. Each repeated argument is one of `object:`, `mutable:`, `id:`, or `pure:` and must match the accepted policy’s `get_invocation` contract. For a repetitive or `for_each` vertex, preserve iterator identity with `nexus execution authorize --execution-id 0x42 --leader-cap 0x43 --walk-index 0 --vertex worker --iteration 1 --out-of 4 fixed-price`. `--iteration` is zero-based, `--out-of` is the total item count, and changing either value selects a different runtime vertex; the handler rejects an iteration that is not smaller than `--out-of`. The CLI help exposes this command shape: ``` Usage: nexus execution authorize [OPTIONS] --execution-id --leader-cap --walk-index --vertex Commands: fixed-price Pay the invocation price snapshotted by the Execution finite-credits Consume one unit from the beneficiary finite credit account time-pass Use the beneficiary time pass account custom Call an arbitrary accepted policy Options: -e, --execution-id --leader-cap --walk-index --vertex --iteration --out-of ``` The `custom` form requires a qualified `::::Policy` and repeated `--argument` values in exact Move order (`object:`, `mutable:`, `id:`, or `pure:`). The command reads the exact active walk, leader capability, ToolCashier, payment source, policy resources, and RuntimeAuthority before submitting the Invocation lock transaction. #### `nexus execution` ``` An Execution is the workflow runtime created after a Task occurrence is dispatched. It contains walks, vertex results, failure evidence, payment locks, and the final runtime outcome. The occurrence remains the durable scheduler record. This command replays ordered history, then follows new object versions until the Execution finishes or the timeout expires. The human view highlights vertex progress, failure reasons, aborts, and the final outcome. Use --json for the complete ordered event records. Identify an Execution directly, or let the CLI resolve it from its occurrence: nexus execution inspect --execution-id 0x42 nexus execution inspect --task-id 0x21 --occurrence-id 7 After runtime inspection, return to the occurrence to settle or verify it: nexus task occurrence inspect --task-id 0x21 --occurrence-id 7 Walk recovery commands are listed by: nexus tap execution --help Usage: nexus execution [OPTIONS] Commands: authorize Authorize one exact active Tool Invocation as a Leader inspect Replay and follow one execution help Print this message or the help of the given subcommand(s) Options: -h, --help Print help (see a summary with '-h') Output: --json Emit machine readable JSON -v, --verbose... Increase diagnostic detail -q, --quiet... Show errors only ``` #### `nexus execution inspect` ``` An Execution is the workflow runtime created after a Task occurrence is dispatched. It contains walks, vertex results, failure evidence, payment locks, and the final runtime outcome. The occurrence remains the durable scheduler record. This command replays ordered history, then follows new object versions until the Execution finishes or the timeout expires. The human view highlights vertex progress, failure reasons, aborts, and the final outcome. Use --json for the complete ordered event records. Identify an Execution directly, or let the CLI resolve it from its occurrence: nexus execution inspect --execution-id 0x42 nexus execution inspect --task-id 0x21 --occurrence-id 7 After runtime inspection, return to the occurrence to settle or verify it: nexus task occurrence inspect --task-id 0x21 --occurrence-id 7 Walk recovery commands are listed by: nexus tap execution --help Usage: nexus execution inspect [OPTIONS] (--execution-id | --task-id --occurrence-id ) Options: -e, --execution-id Execution object ID --task-id Task that owns the occurrence --occurrence-id Occurrence that created the Execution --timeout-secs Maximum observation time [default: 3600] --poll-ms Delay between object reads [default: 1000] -h, --help Print help (see a summary with '-h') Output: --json Emit machine readable JSON -v, --verbose... Increase diagnostic detail -q, --quiet... Show errors only ``` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.talus.network/reference/cli/execution.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.