Merge branch 'main' into codex/arc-auth-quickstart-note

Author: Sharra-writes

.github/workflows/delete-orphan-translation-files.yml

@@ -133,7 +133,28 @@ jobs:
             --label "workflow-generated" \
             --head=$branch_name
           echo "Merge created PR..."
-          retry_command gh pr merge --merge --auto --delete-branch "$branch_name"
+          # Prefer enabling auto-merge so the PR waits for any required
+          # checks before merging. If auto-merge can't be enabled — usually
+          # because all required checks completed before this step ran and
+          # the PR is already immediately mergeable — fall back to a direct
+          # merge. GitHub returns one of these misleading errors in that
+          # case: "Branch does not have required protected branch rules",
+          # "Pull request is in unstable status", or "Pull request is not
+          # in a mergeable state".
+          auto_merge_err=$(mktemp)
+          trap 'rm -f "$auto_merge_err"' EXIT
+          if retry_command gh pr merge --merge --auto --delete-branch "$branch_name" 2>"$auto_merge_err"; then
+            :
+          else
+            cat "$auto_merge_err"
+            if grep -qE "does not have required protected branch rules|unstable status|Pull request is not in a mergeable state" "$auto_merge_err"; then
+              echo "Auto-merge unavailable; PR appears immediately mergeable. Falling back to direct merge."
+              retry_command gh pr merge --merge --delete-branch "$branch_name"
+            else
+              echo "Auto-merge failed with an unexpected error."
+              exit 1
+            fi
+          fi
 
       - uses: ./.github/actions/slack-alert
         if: ${{ failure() && github.event_name != 'workflow_dispatch' }}

.github/workflows/index-general-search-pr.yml

@@ -64,7 +64,7 @@ jobs:
 
           # first sleep to give it a chance to start
           sleep 6
-          curl --retry-connrefused --retry 4 -I http://localhost:4002/
+          curl --retry-connrefused --retry 6 -I http://localhost:4002/
 
       - if: ${{ failure() }}
         name: Debug server outputs on errors

.gitignore

@@ -106,3 +106,6 @@ tmp/
 
 # Localized content from translation repositories
 translations/
+
+# Shared local volume (bufo)
+.local

content/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-aws.md

@@ -70,6 +70,17 @@ Edit the trust policy, adding the `sub` field to the validation conditions. For
 }
 ```
 
+For repositories created after June 18, 2026, or that have opted in to immutable subject claims, the `sub` claim includes immutable owner and repository IDs (not available on {% data variables.product.prodname_ghe_server %}). Make sure your trust policy matches the format your repository uses. For more information, see [AUTOTITLE](/actions/reference/openid-connect-reference#immutable-subject-claims).
+
+```json copy
+"Condition": {
+  "StringEquals": {
+    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
+    "token.actions.githubusercontent.com:sub": "repo:octo-org-123456/octo-repo-456789:ref:refs/heads/octo-branch"
+  }
+}
+```
+
 If you use a workflow with an environment, the `sub` field must reference the environment name: `repo:ORG-NAME/REPO-NAME:environment:ENVIRONMENT-NAME`. For more information, see [AUTOTITLE](/actions/reference/openid-connect-reference#filtering-for-a-specific-environment).
 
 {% data reusables.actions.oidc-deployment-protection-rules %}

content/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-azure.md

@@ -32,6 +32,8 @@ This guide gives an overview of how to configure Azure to trust {% data variable
 
 {% data reusables.actions.oidc-on-ghecom %}
 
+For repositories created after June 18, 2026, and repository renames or transfers after that date, use an immutable default OIDC `sub` claim that includes owner and repository IDs (not available on {% data variables.product.prodname_ghe_server %}). Existing repositories keep the previous format unless they opt in. For more information, see [AUTOTITLE](/actions/reference/openid-connect-reference#immutable-subject-claims).
+
 {% ifversion ghes %}
 {% data reusables.actions.oidc-endpoints %}
   <!-- This note is indented to align with the above reusable. -->

content/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-google-cloud-platform.md

@@ -31,6 +31,8 @@ This guide gives an overview of how to configure GCP to trust {% data variables.
 
 {% data reusables.actions.oidc-on-ghecom %}
 
+For repositories created after June 18, 2026, and repository renames or transfers after that date, use an immutable default OIDC `sub` claim that includes owner and repository IDs (not available on {% data variables.product.prodname_ghe_server %}). Existing repositories keep the previous format unless they opt in. For more information, see [AUTOTITLE](/actions/reference/openid-connect-reference#immutable-subject-claims).
+
 {% ifversion ghes %}
 {% data reusables.actions.oidc-endpoints %}
   <!-- This note is indented to align with the above reusable. -->

content/actions/reference/security/oidc.md

@@ -26,7 +26,7 @@ The OIDC token includes the following claims.
 | ----------- | -----| ---------------------- |
 | `aud`| Audience | By default, this is the URL of the repository owner, such as the organization that owns the repository. You can set a custom audience with a toolkit command: [`core.getIDToken(audience)`](https://www.npmjs.com/package/@actions/core/v/1.6.0) |
 | `iss`| Issuer | The issuer of the OIDC token: {% ifversion ghes %}`https://HOSTNAME/_services/token`{% else %}`https://token.actions.githubusercontent.com`{% endif %} |
-| `sub`| Subject | Defines the subject claim that is to be validated by the cloud provider. This setting is essential for making sure that access tokens are only allocated in a predictable way. |
+| `sub`| Subject | Defines the subject claim that is to be validated by the cloud provider. This setting is essential for making sure that access tokens are only allocated in a predictable way. For repositories using immutable subject claims, the `sub` format includes immutable owner and repository IDs (not available on {% data variables.product.prodname_ghe_server %}). |
 
 ### Additional standard JOSE header parameters and claims
 
@@ -163,6 +163,22 @@ You can configure a subject that includes metadata containing colons. In this ex
 
 {% endif %}
 
+## Immutable subject claims
+
+The OpenID Connect (OIDC) specification requires subject (`sub`) claims to be locally unique and never reassigned. Previously, the default `sub` format used only organization and repository names. If a namespace was recycled, a different owner could create the same subject value.
+
+To help prevent this scenario, repositories created after June 18, 2026 now use an immutable default subject format that includes both the owner ID and repository ID. This rollout does not include {% data variables.product.prodname_ghe_server %}.
+
+* Syntax: `repo:OWNER-ID/REPO-ID:ref:refs/heads/BRANCH`
+* Previous format example: `repo:octo-org/octo-repo:ref:refs/heads/main`
+* Immutable format example: `repo:octo-org-123456/octo-repo-456789:ref:refs/heads/main`
+
+The `-` separator is used between names and IDs because `-` cannot appear in {% data variables.product.github %} usernames or repository names.
+
+Repositories created before June 18, 2026 keep the previous format unless you opt in to immutable subject claims. You can opt in at the organization or repository level by using the OIDC settings UI or REST API.
+
+Repository renames and transfers after June 18, 2026 also move to the immutable subject format.
+
 ## Configuring the subject in your cloud provider
 
 To configure the subject in your cloud provider's trust relationship, you must add the subject string to its trust configuration. The following examples demonstrate how various cloud providers can accept the same `repo:octo-org/octo-repo:ref:refs/heads/demo-branch` subject in different ways:
@@ -174,6 +190,15 @@ To configure the subject in your cloud provider's trust relationship, you must a
 | Google Cloud Platform| `(assertion.sub=='repo:octo-org/octo-repo:ref:refs/heads/demo-branch')` |
 | HashiCorp Vault| `bound_subject="repo:octo-org/octo-repo:ref:refs/heads/demo-branch"` |
 
+For repositories created after June 18, 2026, or that have opted in to immutable subject claims, the `sub` claim includes `owner_id` and `repo_id` as shown in the immutable examples. Update your trust policies to match the format your repository uses. Immutable subject claims are not available on {% data variables.product.prodname_ghe_server %}.
+
+| Cloud provider | Immutable format example |
+| ------ | ----------- |
+| Amazon Web Services | `"token.actions.githubusercontent.com:sub": "repo:octo-org-123456/octo-repo-456789:ref:refs/heads/demo-branch"` |
+| Azure| `repo:octo-org-123456/octo-repo-456789:ref:refs/heads/demo-branch` |
+| Google Cloud Platform| `(assertion.sub=='repo:octo-org-123456/octo-repo#456789:ref:refs/heads/demo-branch')` |
+| HashiCorp Vault| `bound_subject="repo:octo-org-123456/octo-repo-456789:ref:refs/heads/demo-branch"` |
+
 For more information about configuring specific cloud providers, see the guides listed in [AUTOTITLE](/actions/how-tos/security-for-github-actions/security-hardening-your-deployments).
 
 ## Customizing the token claims
@@ -315,6 +340,7 @@ Customizing the claims results in a new format for the entire `sub` claim, which
 > [!NOTE]
 > The `sub` claim uses the shortened form `repo` (for example, `repo:ORG-NAME/REPO-NAME`) instead of `repository` to reference the repository. {% ifversion fpt or ghec or ghes > 3.15 %}
 > Any `:` within the context value will be replaced with `%3A`. {% endif %}
+> For repositories using immutable subject claims (not available on {% data variables.product.prodname_ghe_server %}), `owner_id` and `repo_id` are always included in the `repo` segment of the `sub` claim, even when you customize claims with `include_claim_keys`. You can't remove these IDs from the immutable format.
 
 The following example templates demonstrate various ways to customize the subject claim. To configure these settings on {% data variables.product.prodname_dotcom %}, admins use the REST API to specify a list of claims that must be included in the subject (`sub`) claim.
 

content/actions/tutorials/create-actions/create-a-composite-action.md

@@ -247,11 +247,3 @@ jobs:
         env:
           RANDOM_NUMBER: {% raw %}${{ steps.foo.outputs.random-number }}{% endraw %}
 ```
-
-## Example composite actions on {% data variables.product.github %}
-
-You can find many examples of composite actions on {% data variables.product.github %}.
-
-* [microsoft/action-python](https://github.com/microsoft/action-python)
-* [microsoft/gpt-review](https://github.com/microsoft/gpt-review)
-* [tailscale/github-action](https://github.com/tailscale/github-action)

content/billing/how-tos/set-up-payment/manage-payment-info.md

@@ -1,6 +1,6 @@
 ---
 title: Managing your payment and billing information
-intro: 'Learn how to view and manage your payment information and billing contacts using the new billing platform.'
+intro: 'Learn how to view, modify, and remove your payment information and billing contacts using the new billing platform.'
 versions:
   feature: enhanced-billing-platform
 redirect_from:

content/code-security/getting-started/quickstart-for-securing-your-repository.md

@@ -150,7 +150,7 @@ As an alternative to default setup, you can use advanced setup, which generates
 If you are a repository maintainer, it's good practice to specify a security policy for your repository by creating a file named `SECURITY.md` in the repository. This file instructs users about how to best contact you and collaborate with you when they want to report security vulnerabilities in your repository. You can view the security policy of a repository from the repository’s **{% data variables.product.prodname_security_and_quality_tab %}** tab.
 
 1. From the main page of your repository, click **{% data variables.product.prodname_security_and_quality_tab %}**.
-1. In the left sidebar, under "Reporting", click **{% octicon "law" aria-hidden="true" aria-label="law" %} Policy**.
+1. In the left sidebar, under "Reporting", click **{% octicon "law" aria-hidden="true" aria-label="law" %} Security policy**.
 1. Click **Start setup**.
 1. Add information about supported versions of your project and how to report vulnerabilities.