---
schema_version: 1
route: /t/temporal.md
tool: "temporal"
---

# sincecutoff.com /t/temporal — Temporal CLI

- name: Temporal CLI
- kind: cli
- children: none
- homepage: <https://github.com/temporalio/cli>

Changes to the tools coding agents drive, since a model's training cutoff, each linked to its first-party source. Check installed versions and limitations before acting; a cutoff date does not establish what a model knows.
Original editorial content: [Apache 2.0](https://sincecutoff.com/v1/data-license.txt), by [0xPatrick](https://0xpatrick.dev). Preserve applicable license and [NOTICE](https://sincecutoff.com/notice.txt) attribution when redistributing. Third-party source text and examples retain their own rights. [License scope and attribution](https://sincecutoff.com/v1/license.json).
To stay current, read the changes feed: [`/v1/changes.md?tool=temporal`](https://sincecutoff.com/v1/changes.md?tool=temporal) (or `.json`), adding `since=YYYY-MM-DD` for your training cutoff. Entries for registered children are included; the registry itself is `/v1/tools.json`. How to page and save your place: [llms.txt](https://sincecutoff.com/llms.txt).

### temporal activity adds standalone activity lifecycle commands (2026-09-14)
- slug: temporal-activity-adds-standalone-activity-lifecycle-commands-cc5a175a4148
- score: 0.96

How to use it:

When you need to operate a Standalone Activity, use `temporal activity` to start or execute it, inspect it, wait for its result, or control it by Activity ID. Pause, unpause, reset, and update-options are Experimental; use a list-filter query for supported batch actions.

Examples:

```
temporal activity start --activity-id <activity-id> --type <activity-type> --task-queue <task-queue> --start-to-close-timeout 5m --input '{"some-key":"some-value"}'
```

```
temporal activity describe --activity-id <activity-id>
temporal activity result --activity-id <activity-id>
```

```
temporal activity cancel --query '<list-filter>' --reason <reason>
```

- why_it_matters: Operate a Standalone Activity from the CLI, including inspecting, waiting for, or controlling it.
- sources: <https://github.com/temporalio/cli/releases/tag/v1.9.1>, <https://github.com/temporalio/cli/blob/v1.9.1/internal/temporalcli/commands.yaml>, <https://docs.temporal.io/cli/command-reference/activity>, <https://github.com/temporalio/documentation/blob/main/docs/encyclopedia/activities/standalone-activity.mdx>
- gotchas: "Version: v1.9.1"; "Availability: `pause`, `unpause`, `reset`, and `update-options` remain Experimental."; "--activity-id (required): Activity ID used to target a specific activity; used by start, describe, result, and single-activity control commands."; "--type (required): Activity type to start."; "--task-queue (required): Task Queue for the activity start example."; "--start-to-close-timeout (required): Start-to-close timeout; the documented start example uses `5m`."; "--input: Activity input payload; the documented example supplies JSON."; "--run-id: Activity Run ID; if omitted for describe or result, the latest run is used."; "--query: List Filter query for matching activities; a query is required instead of `--activity-id` for batch cancel."; "--reason: Reason supplied with cancellation; also used for a batch operation."; "Prerequisite: Standalone Activities require Temporal CLI v1.9.1 or higher and Temporal Server v1.32.0 or higher."; "Prerequisite: Pause, unpause, reset, and update-options are Experimental."; "Works against the local dev server; the described flow can be tried without a Cloud namespace."; "Docs conflict: The release note broadly says operator actions can be batched across a query. Official CLI documentation describes query batching for cancel, terminate, and delete; current Temporal documentation says batch pause, unpause, reset, and update-options are unsupported. Confirm the command’s version-specific support before relying on batching those actions."

### Temporal CLI applies one-time move versioning overrides (2026-09-14)
- slug: temporal-cli-applies-one-time-move-versioning-overrides-b53d5eb1f9f6
- score: 0.97

How to use it:

When moving a Workflow to a Worker Deployment Version for one Workflow Task, run `temporal workflow update-options` with `one_time` behavior and the target Deployment Name and Build ID.

Examples:

```
temporal workflow update-options --workflow-id <workflow-id> --versioning-override-behavior one_time --versioning-override-deployment-name <deployment-name> --versioning-override-build-id <build-id>
```

- why_it_matters: Apply a one-time move versioning override from a coding or development workflow.
- sources: <https://github.com/temporalio/cli/releases/tag/v1.9.1>, <https://github.com/temporalio/documentation/blob/main/docs/cli/command-reference/workflow.mdx>
- gotchas: "Version: v1.9.1"; "--workflow-id, -w (required): Workflow ID; use this or `--query`."; "--query, -q (required): SQL-like List Filter for batch operations; use this or `--workflow-id`."; "--versioning-override-behavior (required): Override behavior; accepted values are `unspecified`, `pinned`, `one_time`, and `auto_upgrade`."; "--versioning-override-deployment-name: Target Deployment Name when behavior is `pinned` or `one_time`."; "--versioning-override-build-id: Target Build ID when behavior is `pinned` or `one_time`."; "Prerequisite: Use Temporal CLI v1.9.1 or later for the CLI capability introduced in this release."

### temporal nexus operation adds direct operation commands (2026-09-14)
- slug: temporal-nexus-operation-adds-direct-operation-commands-c57ace64c206
- score: 0.93

How to use it:

When you need to start or manage a Nexus Operation without a caller Workflow, use `temporal nexus operation` with the appropriate lifecycle subcommand; the command group is Experimental.

Examples:

```
temporal nexus operation start --endpoint <endpoint> --service <service> --operation <operation> --operation-id <operation-id> [--input '<json>']
```

```
temporal nexus operation execute --endpoint <endpoint> --service <service> --operation <operation> --operation-id <operation-id> [--input '<json>']
```

```
temporal nexus operation <describe|list|count|result|cancel|terminate> [options]
```

- why_it_matters: Start or manage a Nexus Operation directly during a coding or development workflow.
- sources: <https://github.com/temporalio/cli/releases/tag/v1.9.1>, <https://docs.temporal.io/cli/command-reference/nexus>
- gotchas: "Version: v1.9.1"; "Availability: Experimental."; "--endpoint (required): Nexus Endpoint name."; "--service (required): Nexus Service name."; "--operation (required): Nexus Operation name."; "--operation-id (required): Nexus Operation ID; required by start, execute, describe, result, cancel, and terminate examples/options."; "--input, -i: Input value as JSON; repeatable for multiple arguments. Cannot be combined with --input-file."; "--input-file: Input file path(s); repeatable for multiple arguments. Cannot be combined with --input."; "--input-meta: Repeatable payload metadata as KEY=VALUE; `encoding` overrides the default `json/plain`."; "--input-base64: Assume inputs are base64-encoded and attempt to decode them."; "--id-conflict-policy: Policy for an ID conflict with a running operation: Fail, UseExisting, or TerminateExisting."; "--id-reuse-policy: Policy for reusing an ID from a closed operation: AllowDuplicate or RejectDuplicate."; "--schedule-to-close-timeout: Total time the operation may run."; "--schedule-to-start-timeout: Maximum time to wait for a handler to start the operation or complete it synchronously."; "--start-to-close-timeout: Maximum time to wait for an asynchronous operation to complete after it starts."; "--search-attribute: Repeatable Search Attribute in KEY=JSON_VALUE format; keys must be identifiers."; "--query, -q: Filter operations for list or count."; "--limit: Maximum number of operation executions to display in list."; "--page-size: Maximum number of operation executions to fetch per server request in list."; "--run-id, -r: Run ID of the Nexus Operation; available for cancel, describe, result, and terminate."; "--reason: Reason for cancellation or termination; termination defaults to a message with the current user's name."; "Prerequisite: The command group is Experimental, according to the v1.9.1 release note."; "Prerequisite: The CLI connects to `localhost:7233` by default; use `--address` to specify another Temporal Service gRPC endpoint. The reference lists `--api-key` for requests and TLS connection options."

### temporal worker count reports namespace workers (2026-09-14)
- slug: temporal-worker-count-reports-namespace-workers-c37879658b37
- score: 0.92

How to use it:

When you need the worker count for a namespace, run `temporal worker count`; add `--query` to count a subset. The v1.9.1 release marks this command experimental.

Examples:

```
temporal worker count --namespace <namespace>
```

```
temporal worker count --namespace <namespace> --query 'TaskQueue="<task-queue>"'
```

- why_it_matters: Check the number of workers running in a namespace, optionally narrowed by a query.
- sources: <https://github.com/temporalio/cli/releases/tag/v1.9.1>, <https://github.com/temporalio/documentation/blob/main/docs/cli/command-reference/worker.mdx>
- gotchas: "Version: v1.9.1"; "Availability: Experimental."; "--namespace: Temporal Service namespace; defaults to `default`."; "--query` / `-q: SQL-like `QUERY` List Filter content; narrows the count to a subset."

### temporal Nexus operation CLI adds standalone operation support (2026-09-11)
- slug: temporal-nexus-operation-cli-adds-standalone-operation-support-5ff4034ba898
- score: 0.94

How to use it:

When connecting to an OSS server v1.32.0, start a standalone Nexus operation with `temporal nexus operation start`, supplying its endpoint, service, operation, operation ID, and JSON input. The release note identifies this command group as experimental.

Examples:

```
temporal operator nexus endpoint create --name <endpoint> --target-namespace <namespace> --target-task-queue <task-queue>
```

```
temporal nexus operation start --endpoint <endpoint> --service <service> --operation <operation> --operation-id <operation-id> --input '"<value>"'
```

- why_it_matters: Start or inspect standalone Nexus operations from the CLI when using an OSS server v1.32.0.
- sources: <https://github.com/temporalio/cli/releases/tag/v1.9.0>, <https://github.com/temporalio/cli/pull/1046>
- gotchas: "Version: v1.9.0"; "--name (required): Endpoint name."; "--target-namespace (required): Target namespace for the endpoint."; "--target-task-queue (required): Target task queue for the endpoint."; "--endpoint (required): Endpoint to invoke."; "--service (required): Nexus service to invoke."; "--operation (required): Operation to start."; "--operation-id (required): Operation ID."; "--input: JSON input payload; the source example passes a JSON string."; "Prerequisite: Requires OSS Server v1.32.0."; "Prerequisite: The release note labels the `temporal nexus operation` command group Experimental."; "Requires OSS server version v1.32.0."

### temporal options lists global and connection options (2026-09-11)
- slug: temporal-options-lists-global-and-connection-options-cd490219d41b
- score: 0.95

How to use it:

When you need the global or connection options and their environment variables or config keys, run `temporal options` to display them in tables. Use the `temporal options` hint in root or subcommand help to find the command.

Examples:

```
temporal options
```

- why_it_matters: Find global and connection options, including their environment variables and configuration keys.
- before: Read global options from root help and connection options from subcommand help, where those flags were displayed inline.
- sources: <https://github.com/temporalio/cli/releases/tag/v1.9.0>, <https://github.com/temporalio/cli/pull/1061>, <https://github.com/temporalio/cli/blob/v1.9.0/internal/temporalcli/commands.go>
- gotchas: "Version: v1.9.0"; "Global flags are hidden from root `--help`; connection flags are hidden from subcommand `--help`."

### temporal schedule list-matching-times previews schedule firing times (2026-09-11)
- slug: temporal-schedule-list-matching-times-previews-schedule-firing-times-2603941fbd33
- score: 0.98

How to use it:

When you need to preview a schedule’s matching times in a time range, run `temporal schedule list-matching-times` with its schedule ID, start time, and end time. It lists matching times without running the schedule actions.

Examples:

```
temporal schedule list-matching-times \
  --schedule-id <ScheduleId> \
  --start-time <StartTimestamp> \
  --end-time <EndTimestamp>
```

- why_it_matters: Preview when a schedule would fire during a specified time range without executing workflows.
- sources: <https://github.com/temporalio/cli/releases/tag/v1.9.0>, <https://github.com/temporalio/cli/pull/1047>, <https://raw.githubusercontent.com/temporalio/cli/v1.9.0/internal/temporalcli/commands.yaml>
- gotchas: "Version: v1.9.0"; "--schedule-id (required): Schedule ID."; "--start-time (required): Start of the time range to list matching times; accepts a timestamp."; "--end-time (required): End of the time range to list matching times; accepts a timestamp."; "Preview does not execute workflows."

### temporal standalone activity start supports start delay (2026-09-11)
- slug: temporal-standalone-activity-start-supports-start-delay-6f5ab4e2548e
- score: 0.96

How to use it:

When starting a standalone activity, pass `--start-delay <duration>` to delay its first task; then describe it by activity ID (and optionally run ID) to inspect the result. The v1.9.0 release note says describe text output exposes `StartDelay`.

Examples:

```
temporal activity start --activity-id <ActivityId> --type <ActivityType> --task-queue <TaskQueue> --start-to-close-timeout 30s --start-delay 2s
```

```
temporal activity describe --activity-id <ActivityId> --run-id <RunId>
```

- why_it_matters: Start a standalone activity with a delay and verify the delay in its description.
- sources: <https://github.com/temporalio/cli/releases/tag/v1.9.0>, <https://github.com/temporalio/cli/pull/1113>, <https://github.com/temporal/documentation/blob/main/docs/cli/command-reference/activity.mdx>, <https://github.com/temporal/documentation/blob/main/docs/encyclopedia/activities/standalone-activity.mdx>
- gotchas: "Version: v1.9.0"; "`--activity-id` (required): Activity ID."; "`--type` (required): Activity Type name."; "`--task-queue` (required): Activity task queue."; "`--start-to-close-timeout`: Maximum time for one activity attempt; either this or `--schedule-to-close-timeout` is required."; "`--start-delay`: Duration before dispatching the first activity task; it does not apply to retry attempts."; "`--run-id`: Activity Run ID; if omitted, describe targets the latest run."; "Prerequisite: Current Temporal documentation says standalone activities require Temporal CLI v1.9.1 or higher and Temporal Server v1.32.0 or higher."; "Support is for standalone activity start/execute options."; "`StartDelay` is exposed in activity describe text output."; "Docs conflict: Current Temporal documentation sets the minimum CLI version for standalone activities to v1.9.1, while this card describes v1.9.0 support. The release page says v1.9.0 was published as a pre-release only; v1.9.1 is the first official v1.9.x release. https://github.com/temporalio/cli/releases"

### temporal schedule list-matching-times previews schedule times (2026-07-10)
- slug: temporal-schedule-list-matching-times-previews-schedule-times-0f5b82056f87
- score: 0.98

How to use it:

When you need to preview a schedule over a time range, run `temporal schedule list-matching-times` with its Schedule ID and required start and end timestamps. It lists matching times without running the scheduled actions.

Examples:

```
temporal schedule list-matching-times \
  --schedule-id "<ScheduleID>" \
  --start-time "<RFC3339 start timestamp>" \
  --end-time "<RFC3339 end timestamp>"
```

- why_it_matters: Preview when a schedule would fire within a given time range without executing workflows.
- sources: <https://github.com/temporalio/cli/releases/tag/v1.8.0>, <https://github.com/temporalio/cli/pull/1047>, <https://raw.githubusercontent.com/temporalio/cli/v1.8.0/internal/temporalcli/commands.yaml>
- gotchas: "Version: v1.8.0"; "--schedule-id (required): Schedule ID."; "--start-time (required): Start of time range to list matching times; timestamp."; "--end-time (required): End of time range to list matching times; timestamp."; "Prerequisite: The command is marked Experimental in v1.8.0 CLI documentation."

### temporal activity adds experimental Standalone Activity management (2026-04-29)
- slug: temporal-activity-adds-experimental-standalone-activity-management-411f42edb342
- score: 0.96

How to use it:

When using a dev server, the required Standalone Activity dynamic config is enabled automatically; on a self-hosted server, enable `EnableChasm` and `activity.Enabled` manually. Then use `temporal activity` commands to start or execute an activity, inspect or query it, and wait for its result or cancel or terminate it.

Examples:

```
temporal activity start --activity-id <activity-id> --type <activity-type> --task-queue <task-queue> --start-to-close-timeout 5m --input '<json-input>'
```

```
temporal activity execute --activity-id <activity-id> --type <activity-type> --task-queue <task-queue> --start-to-close-timeout 30s --input '<json-input>'
```

```
temporal activity result --activity-id <activity-id>
```

- why_it_matters: Manage Standalone Activities from the CLI in a development or self-hosted server environment.
- sources: <https://github.com/temporalio/cli/releases/tag/v1.7.0>, <https://github.com/temporalio/cli/pull/986>, <https://github.com/temporalio/cli/blob/v1.7.0/internal/temporalcli/commands.yaml>
- gotchas: "Version: v1.7.0"; "Availability: Experimental"; "--activity-id <id> (required): Identifies the Standalone Activity; used to start it and reference it for result, describe, cancel, or terminate."; "--type <activity-type> (required): Activity type to start or execute."; "--task-queue <task-queue> (required): Task Queue for the activity."; "--start-to-close-timeout <duration> (required): Start-to-close timeout; the documented start example uses `5m`, execute uses `30s`."; "--input <json>: Activity input payload; repeatable payload-input option."; "--run-id <id>: Activity Run ID for standalone activity references; if omitted, the latest run is used."; "--query <visibility-query>: Filters activities for `list` or `count`."; "--reason <text>: Cancellation or termination reason; termination defaults to a message with the current user's name."; "EnableChasm (required): Server dynamic config required for Standalone Activity support; dev server enables it automatically."; "activity.Enabled (required): Server dynamic config required for Standalone Activity support; dev server enables it automatically."; "Prerequisite: The release labels Standalone Activity support Experimental."; "Prerequisite: For self-hosted deployments, enable `EnableChasm` and `activity.Enabled`; `temporal server start-dev` enables both automatically."; "For self-hosted server deployments, `EnableChasm` and `activity.Enabled` must be enabled manually."; "The release says these flags will be on by default starting in server v1.32."; "Docs conflict: Current Temporal documentation says Standalone Activities require CLI v1.9.1+ and Server v1.32.0+. That documentation describes newer versions; the v1.7.0 release says the flags will become default in Server v1.32, so its self-hosted setup requirement is retained here."

### temporal worker deployment create and create-version commands (2026-04-29)
- slug: temporal-worker-deployment-create-and-create-version-commands-89c361a7134a
- score: 0.90

How to use it:

To predefine a Worker Deployment and add a version from a repository workflow, run `temporal worker deployment create`, then `temporal worker deployment create-version` with the deployment name and build ID. For AWS Lambda compute configuration, include the Lambda ARN and the required role and external ID flags.

Examples:

```
temporal worker deployment create --name <deployment-name>
```

```
temporal worker deployment create-version --namespace <namespace> --deployment-name <deployment-name> --build-id <build-id> --aws-lambda-function-arn <lambda-function-arn> --aws-lambda-assume-role-arn <assume-role-arn> --aws-lambda-assume-role-external-id <external-id>
```

- why_it_matters: Create or create a version of a Worker Deployment from a repository workflow.
- sources: <https://github.com/temporalio/cli/releases/tag/v1.7.0>, <https://github.com/temporalio/documentation/blob/main/docs/cli/command-reference/worker.mdx>
- gotchas: "Version: v1.7.0"; "--name (required): Worker Deployment name for `create`."; "--namespace: Namespace; shown in the documented `create-version` example, but not listed as a required option for that command."; "--deployment-name (required): Worker Deployment name for `create-version`."; "--build-id (required): Build ID of the Worker Deployment Version."; "--aws-lambda-function-arn: Lambda function ARN to invoke when there are no active pollers for task queue targets in the Deployment."; "--aws-lambda-assume-role-arn: Role ARN the Temporal server assumes to invoke Lambda; required with `--aws-lambda-function-arn` unless `--aws-lambda-skip-role-and-external-id` is passed."; "--aws-lambda-assume-role-external-id: External ID enforced by the role trust policy; required with `--aws-lambda-function-arn` unless `--aws-lambda-skip-role-and-external-id` is passed."; "--aws-lambda-skip-role-and-external-id: When using a Lambda ARN, omit both assume-role flags if this flag is passed. This choice is mutually exclusive with supplying either assume-role flag."; "Prerequisite: Predefine the Deployment with `create` before calling `create-version`."; "Commands manage Worker Deployments via direct gRPC API calls."

### temporal workflow show adds --reverse history ordering (2026-04-29)
- slug: temporal-workflow-show-adds-reverse-history-ordering-98fdd746b694
- score: 0.97

How to use it:

To view a workflow’s newest history events first, run `temporal workflow show` with its workflow ID and `--reverse`.

Examples:

```
temporal workflow show --workflow-id <workflow-id> --reverse
```

- why_it_matters: Debug a workflow by listing its newest history events first.
- sources: <https://github.com/temporalio/cli/releases/tag/v1.7.0>, <https://github.com/temporalio/documentation/blob/main/docs/cli/command-reference/workflow.mdx>, <https://github.com/temporalio/cli>
- gotchas: "Version: v1.7.0"; "--workflow-id (required): Workflow ID to show."; "--reverse: Fetch event history newest-event-first."; "Prerequisite: Install the Temporal CLI and make the `temporal` binary available on your PATH."; "Docs conflict: Current command reference says `--reverse` cannot be combined with `--follow`; the v1.7.0 release note does not mention this restriction. The current reference is for main, so this restriction is not confirmed for v1.7.0."

### Temporal CLI adds experimental workflow pause and unpause commands (2026-02-05)
- slug: temporal-cli-adds-experimental-workflow-pause-and-unpause-commands-ab24e1067f90
- score: 0.94

How to use it:

When a specific Workflow Execution needs to be held without terminating it, run `temporal workflow pause` with its workflow ID; when it can continue, run `temporal workflow unpause` with that ID.

Examples:

```
temporal workflow pause --workflow-id <WorkflowId> --reason "<reason>"
```

```
temporal workflow unpause --workflow-id <WorkflowId> --reason "<reason>"
```

- why_it_matters: Pause or resume a workflow from the Temporal CLI.
- sources: <https://github.com/temporalio/cli/releases/tag/v1.6.0>, <https://github.com/temporalio/cli/pull/885>, <https://github.com/temporalio/cli/pull/914>, <https://github.com/temporalio/documentation/blob/main/docs/encyclopedia/workflow/workflow-pause.mdx>
- gotchas: "Version: v1.6.0"; "Availability: experimental"; "--workflow-id (required): Identifies the Workflow Execution to pause or unpause."; "--reason: Reason recorded for the pause or unpause operation."; "Prerequisite: Temporal CLI v1.6.0 or later."; "Prerequisite: Self-hosted Temporal requires Server v1.30.0 or later with `frontend.WorkflowPauseEnabled` enabled."; "Prerequisite: Temporal Cloud prerelease access is invite-only."

### Temporal CLI extensions support OAuth client options (2026-02-05)
- slug: temporal-cli-extensions-support-oauth-client-options-44f0302a1bc8
- score: 0.91

How to use it:

When building a CLI extension client, use `ClientOptionsBuilder` with generated `CommonOptions` and `ClientOptions` to build SDK dial options. Store OAuth with `StoreClientOAuth`; set `Address` to persist the profile address, using `${namespace}` when the address should include the runtime namespace.

Examples:

```
builder := &cliext.ClientOptionsBuilder{CommonOptions: common, ClientOptions: client}
opts, err := builder.Build(ctx)
```

```
err := cliext.StoreClientOAuth(cliext.StoreClientOAuthOptions{OAuth: oauth, Address: "<address>/${namespace}"})
```

```
result, err := cliext.LoadClientOAuth(cliext.LoadClientOAuthOptions{})
```

- why_it_matters: Configure OAuth for a CLI extension client and set its address for the active namespace.
- sources: <https://github.com/temporalio/cli/releases/tag/v1.6.0>, <https://github.com/temporalio/cli/pull/892>, <https://github.com/temporalio/cli/pull/913>, <https://raw.githubusercontent.com/temporalio/cli/v1.6.0/cliext/client.go>, <https://raw.githubusercontent.com/temporalio/cli/v1.6.0/cliext/config.oauth.go>, <https://github.com/temporalio/proposals/blob/master/cli/cli-extensions.md>
- gotchas: "Version: v1.6.0"; "ClientOptionsBuilder.CommonOptions (required): Generated common CLI options, including profile configuration."; "ClientOptionsBuilder.ClientOptions (required): Generated client configuration from flags."; "ClientOptionsBuilder.Build(ctx) (required): Builds SDK `client.Options`; returns options and an error. If `ClientConnectTimeout` is set, apply it as a context timeout when dialing."; "LoadClientOAuthOptions.ConfigFilePath: Overrides the config path; empty uses `TEMPORAL_CONFIG_FILE` or the default path."; "LoadClientOAuthOptions.ProfileName: Selects the profile; empty uses `TEMPORAL_PROFILE` or `default`."; "LoadClientOAuthOptions.EnvLookup: Overrides environment lookup; nil uses OS environment lookup."; "StoreClientOAuthOptions.ConfigFilePath: Overrides the config path; empty uses `TEMPORAL_CONFIG_FILE` or the default path."; "StoreClientOAuthOptions.ProfileName: Selects the profile; empty uses `TEMPORAL_PROFILE` or `default`."; "StoreClientOAuthOptions.OAuth: OAuth configuration to store; nil removes OAuth from the profile."; "StoreClientOAuthOptions.Address: Server address to store in the profile; empty leaves address unchanged. `${namespace}` in the address is replaced with the profile namespace when building client options."; "StoreClientOAuthOptions.EnvLookup: Overrides environment lookup; nil uses OS environment lookup."; "OAuthConfig.ClientConfig: OAuth 2.0 client configuration."; "OAuthConfig.Token: OAuth 2.0 token."; "Prerequisite: Use the `github.com/temporalio/cli/cliext` package; its Go API is the extension helper library."; "Prerequisite: When `CommonOptions.ClientConnectTimeout` is set, apply it as a context timeout when dialing."; "The source says use of OAuth with the `default` namespace produces a helpful error message."

### Temporal CLI workflow start accepts headers (2026-02-05)
- slug: temporal-cli-workflow-start-accepts-headers-f1459a68edfd
- score: 0.96

How to use it:

When starting a Workflow Execution with Temporal CLI, use `temporal workflow start` and pass each header as a repeatable `--headers KEY=VALUE` option. Header keys must be identifiers and values must be JSON values.

Examples:

```
temporal workflow start \
  --workflow-id <WorkflowId> \
  --type <WorkflowType> \
  --task-queue <TaskQueue> \
  --headers 'my-header="value"' \
  --headers 'another-header=123'
```

- why_it_matters: Start a workflow with headers set from the Temporal CLI.
- sources: <https://github.com/temporalio/cli/releases/tag/v1.6.0>, <https://github.com/temporalio/cli/pull/883>, <https://docs.temporal.io/cli/command-reference/workflow>
- gotchas: "Version: v1.6.0"; "--headers: Repeatable `KEY=VALUE` workflow header; keys must be identifiers and values must be JSON values. Sets workflow headers, not gRPC headers."; "--workflow-id: Workflow ID; if omitted, the Service generates a unique ID."; "--type (required): Workflow Type name."; "--task-queue (required): Workflow Task queue."