"gh secret set" using selected visibility requires a list of repositories, its optional in the API/browser

Describe the bug

Creating an Organization Secret via github.com allows you to specify the "selected repositories" visibility setting, and initially specify zero repos (you can update the list later).

https://docs.github.com/en/rest/actions/secrets?apiVersion=2022-11-28#create-or-update-an-organization-secret confirms the selected_repository_ids parameter is optional / not required.

Whereas using gh secret set somesecret -b somevalue -o orgname -v selected will error out.

Steps to reproduce the behavior

Create an Organization secret, specify Selected Repositories for Visbiility, but don't specify any repositories.
Confirm the secret is created.
Create a Personal Access Token with Organization Secret level permissions (read/write)
Then try gh secret set somesecret -b somevalue -o orgname -v selected using the Personal Access Token - error.

Expected vs actual behavior

Expected: secret gets created, with "selected" visibility and no repositories specified.

Actual:

> gh secret set somesecret -b somevalue -o orgname -v selected
`--repos` list required with `--visibility=selected`

Usage:  gh secret set <secret-name> [flags]

...

Logs

N/A

@CpuID

Hey @CpuID, thanks for writing this up ✨

We're hesitant to change this validation because gh secret set always overwrites visibility settings on an existing secret. That alone can be confusing, but if we also allow an empty list of --repos a user could accidentally clear the list of repos they have selected.

To help us understand this request more, can you please give us more information about why you want to use the selected visibility with no repos selected?

@BagToad

Hey @BagToad

We're trying to use the Github CLI and Terraform in parallel, to manage an organization secret's value and visibility respectively.

We have a handful of EC2 instances (segregated in different parts of our infrastructure, one per segment currently) that are each generating a secret on boot for the same purpose, and need to store their secret value for use by multiple Github repos in Github Actions. This is where we use the Github CLI to perform the gh secret set operation, and if the secret with the specific key name exists already in the org, when the EC2 instance is replaced it will overwrite the secret value with a new one (intentional, this is our means of secret rotation, replace the EC2 instance and secret at the same time).

We then intend to use Terraform's github_actions_organization_secret_repositories resource to manage the visibility of those secrets respectively. This gets applied after the initial secret creation outside of the EC2 instance startup process. We want to do this separately so we can change the permissions on the secret without rebuilding the EC2 instance (a 5-10~min operation) as new repositories need to use it etc (this will occur fairly regularly as part of a migration to Github we are progressing with). In addition, this provides us an audit trail in git of which repos were granted access to the secret and when, as the Terraform HCL will live in a Github repo.

Ideally, when an updated secret gets written when a new EC2 instance gets spawned, the visibility settings would remain unchanged, and just the secret value would be updated. The fact gh secret set overwrites visibility settings is an issue in itself for us also :)

It would be great if we can maintain the visibility settings independently to maintaining the secret value, to allow this type of use case to succeed.

Thanks!

@CpuID

Thank you @CpuID, that makes sense. I spoke to @andyfeller about this, and here's what we came up with.

We are going to accept an enhancement to add a new flag to gh secret set that could be used in place of --repos. Something like --clear-repos.

The reason we want a separate flag is that gh secret set will always overwrite the repos list, and we want to make it clear that you are deleting the entire repos list when you provide this flag on an existing secret. If we allow an empty --repos or the omission of --repos to clear the , this potentially destructive behavior isn't as clear.

We'll also welcome PRs from you or anyone else to implement this new flag.

Sidenote: We also noticed some API endpoints that may be of interest to you. You can "Add selected repository to an organization secret", avoiding clearing the current repositories list. I suspect the terraform resource you mentioned already uses this.

Acceptance Criteria

Given I want to create a new secret with visibility:selected or update an existing secret's list of repositories,
When I run gh secret set --visibility --clear-repos
Then the secret is created or updated to have no repos selected.

@iamazeem

Hey @iamazeem! Thanks for opening a PR for this and apologies for the delayed response. @williammartin and I were reviewing this and wanted to update the flag name to be clearer and also make some improvements to the AC.

Acceptance Criteria

Given there is no secret
When I run gh secret set <secret_name> -b <secret_value> -o <org> -v selected --no-repos-selected
Then a secret called <secret_name> is created in <org> with a value of <secret_value> with the selected visibility and no repositories selected.

Given there is an existing secret with <secret_name>
When I run gh secret set <secret_name> -b <secret_value> -o <org> -v selected --no-repos-selected
Then that secret is replaced with a value of <secret_value> with the selected visibility and no repositories selected.

When I run gh secret set <secret_name> -b <secret_value> -o <org> -v selected --no-repos-selected --repos
Then then I receive an error message indicating the mutual exclusivity of the --no-repos-selected and --repos flags

When I run gh secret set <secret_name> -b <secret_value> -o <org> --no-repos-selected
Then then --visibility selected is implied

When I run gh secret set <secret_name> -b <secret_value> -o <org> -v <private/all> --no-repos-selected
Then then I receive an error message indicating that --no-repos-selected may only be used with --visibility selected

When I run gh secret set <secret_name> -b <secret_value> -o <org> -v selected
Then then I receive an error message indicating that providing either a list of repos with --repos or --no-repo-selected is required.

When I run gh secret set --help
Then then there is a note about --no-repos-selected that indicates if there are any repos selected on an existing secret, then they will be cleared.

Navigation Menu

Repository navigation

"gh secret set" using selected visibility requires a list of repositories, its optional in the API/browser #9808

Describe the bug

Steps to reproduce the behavior

Expected vs actual behavior

Logs

Acceptance Criteria

Acceptance Criteria

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

"gh secret set" using selected visibility requires a list of repositories, its optional in the API/browser #9808

Description

Describe the bug

Steps to reproduce the behavior

Expected vs actual behavior

Logs

Activity

BagToad commented on Oct 25, 2024

CpuID commented on Oct 25, 2024

BagToad commented on Oct 29, 2024

Acceptance Criteria

BagToad commented on Jul 3, 2025

Acceptance Criteria

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions