---
next_cursor: eyJzY29yZSI6MCwic2VxIjoxOTM2LCJzaW5jZSI6bnVsbCwidG9vbCI6InRlbXBvcmFsIiwidiI6MX0
has_more: true
next: https://sincecutoff.com/v1/changes.md?tool=temporal&score=0&cursor=eyJzY29yZSI6MCwic2VxIjoxOTM2LCJzaW5jZSI6bnVsbCwidG9vbCI6InRlbXBvcmFsIiwidiI6MX0
items: 10
---
# sincecutoff.com changes: temporal

## Temporal CLI adds experimental workflow pause and unpause commands (temporal, 2026-02-05)
Published 2026-10-19
- 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 (temporal, 2026-02-05)
Published 2026-10-19
- 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 (temporal, 2026-02-05)
Published 2026-10-19
- 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."

## temporal activity adds experimental Standalone Activity management (temporal, 2026-04-29)
Published 2026-10-19
- 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 (temporal, 2026-04-29)
Published 2026-10-19
- 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 (temporal, 2026-04-29)
Published 2026-10-19
- 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 schedule list-matching-times previews schedule times (temporal, 2026-07-10)
Published 2026-10-19
- 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 Nexus operation CLI adds standalone operation support (temporal, 2026-09-11)
Published 2026-10-19
- 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 (temporal, 2026-09-11)
Published 2026-10-19
- 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 (temporal, 2026-09-11)
Published 2026-10-19
- 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."

Next: https://sincecutoff.com/v1/changes.md?tool=temporal&score=0&cursor=eyJzY29yZSI6MCwic2VxIjoxOTM2LCJzaW5jZSI6bnVsbCwidG9vbCI6InRlbXBvcmFsIiwidiI6MX0
Save `next_cursor`; next visit, pass it to get only what was published since.
<!-- end of page -->