Improvements on zowe config list command

Is your feature or enhancement request related to a problem or limitation? Please describe

This is an enhancement request for zowe config list command.

I wish I am able to retrieve only a specific key configured in the latest Zowe CLI Team configuration file.
My workflow often includes me switching between remote z/OS hosts on my workstatio. I update my project_base configuration(sample shown below) host value from host1 to host2.

        "project_base": {
            "type": "base",
            "properties": {
                "host": "host1.example.net",
                "rejectUnauthorized": true
            },
            "secure": [
                "user",
                "password"
            ]
        }

I don't have a Zowe CLI native way of accessing the updated property from the updated Zowe CLI configuration. I often need to use this value for further validation in my script.

Describe your enhancement idea

My idea is that the zowe config list "profiles" oepration can be enhanced to provide more granular information.

An updated command input looks like below:
$zowe config list "profiles.project_base.properties.host"

This command input will return only the host value set in the zowe.config.json file.

in our example, it should return the text:

$zowe config list "profiles.project_base.properties.host"
host1.example.net

If a property is not set or undefined, an empty line can be produced.
The secure parameters should be blocked from retrieval through this mechanism.

Describe alternatives you've considered

To retrieve the configured host, I used jq with the json formatted output like below:

zowe config list --rfj | jq -r ".data.profiles.project_base.properties.host"

This provides only the chosen property, I need to validate or review.
This also makes me dependent on external dependency like jq.
Most workstations do not have jq installed by default and scripts end up broken across the team.

If Zowe CLI provides this additional capabilty, it would be easy to keep the scripts and validations for properties tied together in the same script.

Provide any additional context

Expected command behavior:

# successful response
$ zowe config list "profiles.project_base.properties.host"
host1.example.net

# error response with message like below
$zowe config list "profiles.project_base.properies.username"
secure variables cannot be accessed

# not found variables
$zowe config list "profiles.project_base.properties.basepath"

<no result>

Thank you for raising this enhancement request.
The community has 90 days to vote on it.
If the enhancement receives at least 5 upvotes, it is added to our development backlog.
If it receives fewer votes, the issue is closed.

Hi, Thanks for the enhancement request.

I think it makes sense to have a "get" operation to get a particular property out of a profile for completeness.

I do have a question however on your use case:

My workflow often includes me switching between remote z/OS hosts on my workstatio. I update my project_base configuration(sample shown below) host value from host1 to host2.

Curious if there is a reason you don't just have one profile per host and switch between the profiles you're using per command ?

For instance you could have profiles sys1, sys2, sys3 , and then execute your commands with an argument like --zosmf-p sys2 . That would prevent you from needing to edit your profile every time you switch hosts.

Hello, thank you for your response. You make a valid point regarding the option of creating multiple profiles per host and specifying them with command-line arguments (such as --zosmf-p).

However, in our setup, relying on default profiles and switching context centrally via zowe config set is much more effective due to the following three use cases:

Shared LPAR System Configuration: Work is conducted across shared LPAR configurations with shared disks and mount points. Maintaining a single team configuration avoids confusion among team users while enabling easy workstation-level customization.
Static Automation Pipelines: Zowe CLI commands are executed within automation pipelines maintained as static code in source repositories without profile flags. Using default profiles ensures seamless consistency and avoids discrepancies between local execution and pipeline runs.
Python and Java Execution Wrappers: Zowe CLI operations are embedded within custom Python and Java wrapper scripts. Adopting individual host profiles would necessitate code changes across multiple wrapper scripts every time target hosts switch.

By updating the configuration property directly:

zowe config set "profiles.project_base.properties.host" "sys1.example.net"

We can execute the exact same set of commands across local, pipeline, and wrapper environments without requiring code modifications or per-command profile parameters.

Thanks for sharing more information about your workflow. In the interim, without having the zowe config get command available, I would suggest to try setting the ZOWE_OPT_HOST environmental variable which wouldn't require you to change scripts or command arguments

Navigation Menu

Repository navigation

Improvements on `zowe config list` command #2899

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Improvements on zowe config list command #2899

Description

Activity

github-actions commented on Sep 18, 2026

CBforZ commented on Sep 23, 2026

balanpaulrajan commented on Sep 24, 2026

CBforZ commented on Sep 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Improvements on `zowe config list` command #2899