GitHub API Bug: Code Security Configuration Creates 500 Error, Impacting Developer Productivity

In the world of API-driven development, smooth and predictable interactions are crucial for maintaining high developer productivity. A recent discussion on GitHub's community forum highlighted a perplexing bug affecting the GitHub API for code security configurations, specifically when attempting to create a configuration with delegated bypass reviewers.

The Unexpected HTTP 500 on Code Security Configuration Creation

A user reported an issue where using the POST /orgs/{org}/code-security/configurations endpoint to create an organization-level code security configuration returns an HTTP 500 Internal Server Error. This occurs specifically when the request body includes the secret_scanning_delegated_bypass_options.reviewers block. The most frustrating aspect? Despite the server error, the configuration is actually created successfully on GitHub's side.

The Problem in Detail

The core of the issue lies in the server's response code. While a successful creation should yield an HTTP 201 Created, including the reviewers block triggers a 500 with an empty response body. This behavior stands in stark contrast to two key scenarios:

• Creating without reviewers: An identical POST request that omits the reviewers block successfully returns a 201 Created.
• Updating to add reviewers: A subsequent PATCH request to an existing configuration (created without reviewers) to add the same secret_scanning_delegated_bypass_options.reviewers successfully returns an HTTP 200 OK.

This suggests the problem is isolated to the initial creation process when reviewers are specified, potentially indicating a regression, as this functionality appeared to work previously.

Impact on Automation and Developer Productivity

This bug presents significant challenges for automated provisioning and configuration management tools. API clients are typically designed to treat 5xx errors as failures, often triggering retry mechanisms. In this specific case, a retry would then hit a 422 "Name has already been taken" error because the configuration was, in fact, created during the initial "failed" attempt. This leaves an orphaned configuration and breaks automated workflows, directly hindering developer productivity and making it harder to meet engineering OKRs related to security automation.

Reproduction Steps and Environment

The issue was reproduced against GitHub Enterprise Cloud (observed June 2026) using API version 2022-11-28. The reporter provided clear curl examples:

ORG="your-org"
TOKEN="***"
TEAM_ID=$(gh api -X POST "orgs/$ORG/teams" -H "Authorization: token $TOKEN" -f name="bypass-reviewers" --jq '.id')

# (A) create WITH reviewers -> 500 (but the config is created)
curl -sS -o /dev/null -w "%{\http_code}
" -X POST \
-H "Authorization: token $TOKEN" -H "Accept: application/vnd.github+json" \
"https://api.github.com/orgs/$ORG/code-security/configurations" \
-d "{"name":"repro-with-reviewers","advanced_security":"enabled","secret_scanning":"enabled","secret_scanning_push_protection":"enabled","secret_scanning_delegated_bypass":"enabled","secret_scanning_delegated_bypass_options":{"reviewers":[{"reviewer_id":$TEAM_ID,"reviewer_type":"TEAM"}]}}"
# -> 500

# (B) identical request WITHOUT the reviewers block -> 201
curl -sS -o /dev/null -w "%{\http_code}
" -X POST \
-H "Authorization: token $TOKEN" -H "Accept: application/vnd.github+json" \
"https://api.github.com/orgs/$ORG/code-security/configurations" \
-d "{"name":"repro-no-reviewers","advanced_security":"enabled","secret_scanning":"enabled","secret_scanning_push_protection":"enabled","secret_scanning_delegated_bypass":"enabled"}"
# -> 201

# (C) PATCH the (B) config to ADD the same reviewers -> 200
# (CONFIG_ID from the 201 response of B)
curl -sS -o /dev/null -w "%{\http_code}
" -X PATCH \
-H "Authorization: token $TOKEN" -H "Accept: application/vnd.github+json" \
"https://api.github.com/orgs/$ORG/code-security/configurations/CONFIG_ID" \
-d "{"secret_scanning_delegated_bypass_options":{"reviewers":[{"reviewer_id":$TEAM_ID,"reviewer_type":"TEAM"}]}}"
# -> 200

Workaround for Automated Workflows

Until this GitHub API bug is resolved, the recommended workaround for teams aiming to maintain seamless developer productivity is a two-step process:

1. First, create the code security configuration via the POST /orgs/{org}/code-security/configurations endpoint, ensuring the secret_scanning_delegated_bypass_options.reviewers block is omitted from the initial request.
2. Once the configuration is successfully created (receiving a 201 Created), perform a follow-up PATCH /orgs/{org}/code-security/configurations/CONFIG_ID request to add the desired reviewers.

This approach, while requiring an extra API call, ensures that automated provisioning processes can complete without encountering the misleading 500 error and subsequent 422 conflicts, keeping your security configurations in line with your engineering OKRs.