[Feature Request] Let me specify the encoding for my inputs. Bonus for doing this with outputs too...

[mnichols]

Is your feature request related to a problem? Please describe.

We are too assumptive about JSON usage everywhere...We need to support arbitrary encodings for at least inputs (if not outputs also...) , for example encoding=json/protobuf.

We support this on some commands while others we do not.

Describe the solution you'd like

Support protobufs for real from the CLI since we include it as default data converter in most SDKs OOTB.

We really should allow specifying the OUTPUT encoding too since protobufs are a result too, not just an input.
Basically, these commands need to be consistency and real-world.

Additional context

I did the hard part for you in identifying which commands lack proper support for input encoding:

Category	Command	Payload Flag	Meta/Encoding Switch?
Workflow	start / execute	--input	Yes (--input-meta)
Workflow	update start	--input	Yes (--input-meta)
Workflow	signal	--input	No
Workflow	query	--input	No
Activity	complete	--result	No
Activity	fail	--detail	No
Activity	heartbeat	--details	No
Batch	signal	--input	No
Schedule	create / update	--input	Yes (--input-meta)

[chaptersix]

Input Encoding Audit

Every command that accepts a payload-bearing flag, whether it currently supports encoding control or not:

Commands with --input-meta support (via payload-input option-set)

These commands accept --input, --input-file, --input-meta, and --input-base64:

Command	SAA	Notes
workflow start	--
workflow execute	--
workflow query	--
workflow signal	--
workflow signal-with-start	--	--input-meta + --signal-input-meta
workflow update start	--	--input-meta + --update-input-meta
workflow update execute	--	--input-meta + --update-input-meta
workflow start-update-with-start	--	--input-meta + --update-input-meta
workflow execute-update-with-start	--	--input-meta + --update-input-meta
schedule create	--
schedule update	--
activity start	SAA
activity execute	SAA

Commands with payload flags that lack encoding control

Command	Flag	Payload type	SAA	Notes
activity complete	--result	Result payload	Both	Hardcodes json/plain. Needs --result-meta.
activity fail	--detail	Failure details payload	Both	Hardcodes json/plain. Needs --detail-meta.

Commands with JSON-only payload flags (no encoding control, but possibly should)

These flags carry data that becomes payloads but are always encoded as JSON. Worth considering whether these need encoding control too:

Command(s)	Flag	Notes
workflow start/execute/signal-with-start + all update-with-start variants	--memo	Always JSON. Encoding control would be needed for protobuf memos.
workflow start/execute/...	--search-attribute	Always JSON. SA values go through server-side indexing so this is likely fine as-is.
workflow start/execute/...	--headers	Always JSON KEY=VALUE pairs. Encoding control could matter if headers carry binary/protobuf data.
activity start/execute	--search-attribute	SAA. Same as above.
activity start/execute	--headers	SAA. Same as above.

activity heartbeat is not a CLI command -- heartbeating is done by worker SDKs, so it's not applicable here.

Output Encoding Support

"Output encoding support" means: when a command displays a result payload (e.g. the return value of a workflow or activity), the CLI needs to decode that payload from its wire encoding back into something human-readable. Today this silently fails for protobuf-encoded results.

How the CLI decodes results today

Commands that display results all follow the same pattern:

var value any
converter.GetDefaultDataConverter().FromPayload(payload, &value)

The default DataConverter chains these converters in order:

Encoding	Converter	CLI can decode?
binary/null	NilPayloadConverter	Yes
binary/plain	ByteSlicePayloadConverter	Yes
json/protobuf	ProtoJSONPayloadConverter	No -- see below
binary/protobuf	ProtoPayloadConverter	No -- see below
json/plain	JSONPayloadConverter	Yes

Why protobuf decoding fails

The proto converters require a concrete proto.Message type to unmarshal into. But the CLI passes *any (an interface), so the converters immediately return an error:

// From the SDK's proto converter:
if originalValue.Kind() == reflect.Interface {
    return fmt.Errorf("value type: %s: %w", ..., ErrValuePtrMustConcreteType)
}

Even if the CLI passed a concrete type, it would need the user's generated Go proto types compiled in. The CLI only has Temporal's own API protos -- user-defined message types like my.package.MyResult don't exist in the binary. The result is <failed converting: ...> for any protobuf-encoded payload.

Prior art: how other CLIs handle this

Every major CLI that works with externally-defined protobufs (grpcurl, ghz, evans, buf curl) supports the same three type-resolution sources:

1. Server reflection -- the server streams its own FileDescriptorProto messages on demand. Zero config, but requires server support. Not applicable for Temporal -- the Temporal server doesn't know user-defined proto types.

2. FileDescriptorSet file (.binpb / .protoset / .desc) -- a pre-compiled binary containing all proto type definitions and their transitive dependencies. This is the offline/CI-friendly path and the most common approach.

3. Raw .proto files with import paths -- most fragile, requires the user to specify all import directories.

Flag naming varies but the pattern is consistent:

Tool	Descriptor file flag	Proto file flag
grpcurl	--protoset	--proto + --import-path
ghz	--protoset	--proto + --import-paths
evans	--desc	--proto + --path
buf curl	--schema (unified)	--schema (unified)

A FileDescriptorSet is a protobuf message defined in google/protobuf/descriptor.proto -- literally "the proto that describes protos." It contains the full schema (message types, fields, enums, services) plus all transitive imports, making it fully self-contained. Users generate them with:

buf build -o myservice.binpb
# or
protoc --descriptor_set_out=myservice.binpb --include_imports -I ./proto myservice.proto

What would be needed

This is a first pass -- there may be a better approach, but here's one way it could work:

1. --proto-descriptor (or --protoset to match grpcurl convention): A flag accepting a path to a compiled FileDescriptorSet. Since server reflection isn't applicable here (the Temporal server doesn't host user proto types), the descriptor file is the practical choice.

   The decoding flow would be:

   • Read the payload's encoding metadata (binary/protobuf or json/protobuf)
   • Read the payload's messageType metadata (e.g. my.package.MyResult) -- SDKs set this automatically when encoding proto payloads
   • Look up that message type in the descriptors loaded from the file
   • Create a dynamicpb.Message (from google.golang.org/protobuf/types/dynamicpb) -- this allows working with proto messages without compiled Go types
   • Unmarshal the payload bytes into the dynamic message (proto.Unmarshal or protojson.Unmarshal)
   • Marshal the dynamic message to JSON via protojson.Marshal for display

   This would bypass the SDK's DataConverter for the output path -- it would be CLI-specific decoding logic. In the Go ecosystem, google.golang.org/protobuf/reflect/protodesc or github.com/jhump/protoreflect are commonly used for this (grpcurl, ghz, and similar tools are all built on the latter).

2. --output-file: Write raw result payload bytes to a file instead of (or in addition to) printing to stdout. This lets users decode results externally with their own tooling, which is useful for:

   • Protobuf results when providing a descriptor set is inconvenient
   • Large binary payloads
   • Any custom encoding the CLI doesn't understand

Commands that would benefit from output support

Command	Currently prints result?	SAA
workflow execute	Yes	--
workflow result	Yes	--
workflow describe	Yes (includes result in output)	--
activity execute	Yes	SAA
activity result	Yes	SAA
activity describe	Yes (with --raw or JSON output)	SAA

[mnichols]

• Activity Heartbeating is done via an async activity client with the SDK even outside of a Worker and details need to be sent sometimes with that. I dont know why we say CLI doesnt support it or isn't needed.
• I dont know what SAA is so I'm not sure how to read your tables
• TBH I'm not as concerned about the decoding as the fact we simply cant use some CLI commands at all due to inability to specify the encoding, but it seems like your --protoset file is a great addition to get the best of both worlds!

[chaptersix]

• Activity Heartbeating is done via an async activity client with the SDK even outside of a Worker and details need to be sent sometimes with that. I dont know why we say CLI doesnt support it or isn't needed.
• I dont know what SAA is so I'm not sure how to read your tables
• TBH I'm not as concerned about the decoding as the fact we simply cant use some CLI commands at all due to inability to specify the encoding, but it seems like your --protoset file is a great addition to get the best of both worlds!

SAA: Standalone Activities. I used that branch when doing this analysis since is seemed like some of the command you mentioned might be related to it.

TBH I'm not as concerned about the decoding as the fact we simply cant use some CLI commands at all due to inability to specify the encoding, but it seems like your --protoset file is a great addition to get the best of both worlds!
Are you referencing both input and output here?

Adding the missing input-meta's is pretty straight forward but for output we'll need to go through a bit more processes to get that done.