@htekdev/actions-debugger 1.0.123 → 1.0.125

package/errors/runner-environment/runner-environment-230.yml

@@ -0,0 +1,129 @@
+id: runner-environment-230
+title: 'setup-python installs free-threaded Python (3.13t / 3.14t) as broken 0-byte symlink on windows-11-arm64'
+category: runner-environment
+severity: error
+tags:
+  - setup-python
+  - free-threaded
+  - python-3.13t
+  - python-3.14t
+  - windows-11-arm64
+  - symlink
+  - arm64
+  - GIL
+patterns:
+  - regex: 'Remove-Item.+arm64-freethreaded.+python\.exe.+because it does not exist'
+    flags: 'i'
+  - regex: 'Fatal Python error: Failed to import encodings module'
+    flags: 'i'
+  - regex: 'ModuleNotFoundError: No module named .encodings.'
+    flags: 'i'
+  - regex: 'Error happened during pip installation / upgrade'
+    flags: 'i'
+error_messages:
+  - "[error] Remove-Item : Cannot find path 'C:\\hostedtoolcache\\windows\\Python\\3.13.3-freethreaded\\arm64-freethreaded\\python.exe' because it does not exist."
+  - '[error] Fatal Python error: Failed to import encodings module'
+  - '[error] ModuleNotFoundError: No module named ''encodings'''
+  - '[error] Error happened during pip installation / upgrade'
+root_cause: |
+  The `win32-arm64-freethreaded` distribution zip for Python 3.13t and 3.14t
+  contains `python.exe` and `python3.exe` as **symlinks** (Windows reparse
+  points) that point to the version-specific binary (e.g. `python3.13t.exe`).
+
+  When `actions/setup-python` extracts the zip to the tool cache, the symlink
+  target does not exist at the expected relative path inside the extracted
+  directory. This leaves `python.exe` and `python3.exe` as **dangling 0-byte
+  reparse points** rather than working executables.
+
+  The setup script (`setup.ps1`, line 131) then attempts to remove `python.exe`
+  before placing the shim — but because the file is a dangling reparse point,
+  PowerShell cannot find it and throws:
+
+    `Remove-Item : Cannot find path '...\arm64-freethreaded\python.exe'
+     because it does not exist.`
+
+  Even if this error is swallowed, any subsequent attempt to invoke the
+  interpreter fails because the `python.exe` reparse point has no valid target.
+  The interpreter cannot locate its standard library, resulting in:
+
+    `Fatal Python error: Failed to import encodings module`
+
+  Non-free-threaded arm64 builds (`3.11`, `3.12`, `3.13`) are NOT affected
+  because their zips contain real executable files rather than symlinks.
+  x64 free-threaded builds are also unaffected.
+
+  This bug is present in `actions/setup-python` v5.x and v6.x when
+  `windows-11-arm64` runners are used. It was reported in April 2026 and
+  assigned for fix; check actions/setup-python#1307 for the patched release.
+fix: |
+  **Workaround 1 (recommended until patched):** Use a non-arm64 runner for
+  free-threaded Python testing. The x64 free-threaded wheels work correctly on
+  `windows-latest` or `windows-2025`:
+
+    ```yaml
+    runs-on: windows-latest  # x64 runner
+    ```
+
+  **Workaround 2:** Install free-threaded Python from NuGet on arm64 runners
+  rather than using `actions/setup-python`:
+
+    ```powershell
+    nuget install Microsoft.Python.Python.3.13-freethreaded.Arm64 -Version 3.13.3 -OutputDirectory .python
+    ```
+
+  **Workaround 3:** If you need arm64 + free-threaded specifically, test on
+  a Linux arm64 runner (`ubuntu-24.04-arm`) where the free-threaded build
+  does not have the symlink issue.
+
+  **Long-term:** Upgrade to the patched `actions/setup-python` version once
+  released (track actions/setup-python#1307).
+fix_code:
+  - language: yaml
+    label: 'Run free-threaded Python tests on x64 instead of arm64 until fix ships'
+    code: |
+      jobs:
+        test-freethreaded:
+          # Use x64 runner — free-threaded Python on windows-11-arm64 is broken
+          # (setup-python#1307). Switch back when the fix ships.
+          runs-on: windows-latest
+          steps:
+            - uses: actions/checkout@v4
+            - uses: actions/setup-python@v6
+              with:
+                python-version: '3.13t'  # free-threaded; works on x64
+            - run: python --version
+            - run: python -c "import sys; print(sys._is_gil_enabled())"
+  - language: yaml
+    label: 'Use a matrix to run standard Python on arm64 and free-threaded on x64'
+    code: |
+      jobs:
+        test:
+          strategy:
+            matrix:
+              include:
+                # Standard arm64 — works fine
+                - os: windows-11-arm64
+                  python-version: '3.13'
+                # Free-threaded — x64 only until setup-python#1307 is fixed
+                - os: windows-latest
+                  python-version: '3.13t'
+          runs-on: ${{ matrix.os }}
+          steps:
+            - uses: actions/checkout@v4
+            - uses: actions/setup-python@v6
+              with:
+                python-version: ${{ matrix.python-version }}
+prevention:
+  - 'When adding free-threaded Python (3.13t, 3.14t) to a matrix, verify the runner OS — windows-11-arm64 has a broken symlink issue; use windows-latest (x64) instead.'
+  - 'Pin actions/setup-python to a known-good version and monitor actions/setup-python#1307 for the fix release before upgrading on arm64 free-threaded jobs.'
+  - 'After setting up free-threaded Python, add a smoke-test step (`python -c "import sys; print(sys.version)"`) early in the job to catch a broken interpreter before the full test suite runs.'
+  - 'Check that python.exe in the tool cache is a real executable, not a 0-byte reparse point, by running `(Get-Item python.exe).Length -gt 0` in a PowerShell step on windows-arm64.'
+docs:
+  - url: 'https://github.com/actions/setup-python/issues/1307'
+    label: 'actions/setup-python#1307 — setup-python fails for free-threaded Python (3.13t / 3.14t) on windows-11-arm64'
+  - url: 'https://github.com/onnx/onnx/actions/runs/24930991133'
+    label: 'Example failing CI run (onnx/onnx)'
+  - url: 'https://docs.python.org/3/whatsnew/3.13.html#free-threaded-cpython'
+    label: 'Python 3.13 — Free-threaded CPython (experimental no-GIL build)'
+  - url: 'https://github.com/actions/setup-python'
+    label: 'actions/setup-python — GitHub repository'

package/errors/runner-environment/runner-environment-231.yml

@@ -0,0 +1,90 @@
+id: runner-environment-231
+title: 'setup-java hangs indefinitely at "Trying to resolve the latest version from remote"'
+category: runner-environment
+severity: error
+tags:
+  - setup-java
+  - version-resolution
+  - hang
+  - network
+  - JDK
+  - distribution
+  - timeout
+  - temurin
+patterns:
+  - regex: 'Trying to resolve the latest version from remote'
+    flags: 'i'
+  - regex: 'setup-java.+Trying to resolve.+version'
+    flags: 'i'
+error_messages:
+  - 'Trying to resolve the latest version from remote'
+root_cause: |
+  When `java-version` is specified without a full patch version (e.g., `'21'`
+  or `'17'`), `actions/setup-java` must contact the JDK distribution's upstream
+  release manifest API to resolve the latest matching release. Before the fix
+  added in later versions of the action, this HTTP request was issued without a
+  timeout. When the upstream distribution endpoint (Eclipse Temurin, Amazon
+  Corretto, Microsoft JDK, etc.) was slow or unreachable — even transiently —
+  the resolution step could stall indefinitely, wedging the job until the
+  workflow-level `timeout-minutes` expired.
+
+  This affected all distributions that require a remote lookup for the latest
+  version, and was particularly impactful in environments with restricted or
+  intermittently degraded outbound network connectivity. The action would print
+  "Trying to resolve the latest version from remote" and then produce no further
+  output until the job hit its overall timeout.
+
+  The root cause was reported with 24+ community reactions in
+  actions/setup-java#897. The action was subsequently updated with improved
+  retry logic and enhanced error messages that surface the endpoint being
+  queried, making failures diagnosable.
+fix: |
+  **Immediate workaround (always recommended):** Pin an explicit full or
+  three-part version to bypass the remote manifest lookup entirely:
+
+  ```yaml
+  - uses: actions/setup-java@v4
+    with:
+      java-version: '21.0.3'  # Explicit patch version — no remote resolution needed
+      distribution: 'temurin'
+  ```
+
+  **Alternative:** Upgrade `actions/setup-java` to the version that includes
+  retry/timeout improvements (v4.2.2 or later). The updated action adds
+  timeouts and surfaces the endpoint URL in error output so stalls are
+  diagnosable rather than silent hangs.
+
+  **For self-hosted runners with restricted outbound access:** Explicitly add
+  the JDK distribution manifest endpoints to your allowlist, or pin exact
+  versions to eliminate remote lookups entirely.
+fix_code:
+  - language: yaml
+    label: 'Pin explicit patch version to avoid remote resolution'
+    code: |
+      - name: Set up JDK 21
+        uses: actions/setup-java@v4
+        with:
+          # Explicit 3-part version — skips "Trying to resolve the latest
+          # version from remote" entirely
+          java-version: '21.0.3'
+          distribution: 'temurin'
+  - language: yaml
+    label: 'Use version file to avoid hardcoding version while skipping remote lookup'
+    code: |
+      # Define your JDK version in .java-version or .tool-versions
+      # When java-version-file is present, no remote lookup is needed:
+      - name: Set up JDK
+        uses: actions/setup-java@v4
+        with:
+          java-version-file: '.java-version'
+          distribution: 'temurin'
+prevention:
+  - 'Always pin an explicit JDK patch version (e.g., 21.0.3) or use a version file to eliminate remote manifest lookups and prevent hang-on-stall failures.'
+  - 'Set `timeout-minutes` on individual steps or jobs so a stalled remote lookup kills the step quickly rather than consuming the full runner allocation.'
+  - 'Monitor outbound network connectivity from self-hosted runners to JDK distribution APIs (e.g., api.adoptium.net for Temurin) and add these endpoints to firewall/proxy allowlists.'
+  - 'Use `actions/setup-java@v4.2.2` or later which includes retry logic and improved error messages for remote resolution failures.'
+docs:
+  - url: 'https://github.com/actions/setup-java/issues/897'
+    label: 'actions/setup-java#897 — Trying to resolve the latest version from remote (indefinite hang)'
+  - url: 'https://github.com/actions/setup-java#supported-version-syntax'
+    label: 'actions/setup-java — Supported version syntax (pin exact versions to avoid remote lookup)'

package/errors/runner-environment/runner-environment-232.yml

@@ -0,0 +1,131 @@
+id: runner-environment-232
+title: 'Self-hosted runner started as a service (svc.sh/svc.cmd) does not load user PATH from shell profile'
+category: runner-environment
+severity: error
+tags:
+  - self-hosted
+  - PATH
+  - svc.sh
+  - service
+  - environment-variables
+  - bash
+  - profile
+  - command-not-found
+patterns:
+  - regex: '(?:command not found|No such file or directory).+(?:\/home\/.+\/|~\/.+\/|GOPATH|cargo\/bin|\.local\/bin)'
+    flags: 'i'
+  - regex: '(?:bash|sh):.+: (?:command not found|No such file or directory)'
+    flags: 'i'
+error_messages:
+  - '/bin/bash: my-tool: command not found'
+  - 'bash: /home/runner/.local/bin/my-tool: No such file or directory'
+  - 'Error: Unable to locate executable file: my-tool. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable.'
+root_cause: |
+  When the self-hosted runner is registered and started as a system service
+  using `svc.sh install && svc.sh start` (Linux/macOS) or
+  `svc.cmd install` (Windows), the service is launched by the OS service
+  manager (systemd, launchd, or Windows SCM) rather than interactively by
+  the user. As a result:
+
+  1. **Shell profile files are NOT sourced.** The service process never runs
+     `~/.bashrc`, `~/.bash_profile`, `~/.profile`, or `~/.zshrc`, so any
+     `export PATH=...` statements in those files have no effect on the runner
+     process or any job steps it spawns.
+
+  2. **Step shells use `--noprofile --norc` by default.** Even when job steps
+     invoke `bash`, the runner uses `bash --noprofile --norc -e -o pipefail`
+     (or equivalent), which explicitly disables sourcing of profile files.
+     This means binaries installed in user-specific directories — such as
+     `~/.local/bin`, `~/.cargo/bin`, `~/go/bin`, `~/.nvm/versions/node/*/bin`,
+     or any path added via `nvm`, `rbenv`, `pyenv`, `asdf`, etc. — are missing
+     from `PATH` in job steps even if they work fine in an interactive terminal.
+
+  3. **The runner's `.env` file is the authoritative PATH source.** The runner
+     process reads environment variables from a `.env` file at startup
+     (typically at `<runner-install-dir>/.env`). This file is NOT automatically
+     populated when the service is installed.
+
+  This is a common trap when developers install tools as their user (e.g.,
+  `cargo install`, `npm install -g`, `go install`, `pip install --user`) and
+  then register a self-hosted runner. Everything works in an interactive
+  terminal but fails when the service-started runner tries to execute the same
+  commands.
+fix: |
+  **Option 1 (recommended): Add paths to the runner's `.env` file**
+  Edit `<runner-install-dir>/.env` and append the needed PATH entries. The
+  runner reads this file at startup and merges it into the environment for all
+  job steps:
+
+  ```bash
+  # Append to <runner-install-dir>/.env
+  PATH=/home/runner/.cargo/bin:/home/runner/.local/bin:/home/runner/go/bin:$PATH
+  ```
+
+  Restart the service after editing: `sudo svc.sh stop && sudo svc.sh start`
+
+  **Option 2: Use `$GITHUB_PATH` in the workflow**
+  Add a step early in the job to append the needed paths using the
+  `$GITHUB_PATH` mechanism — this persists for all subsequent steps in the job:
+
+  ```yaml
+  - name: Add user bins to PATH
+    run: echo "$HOME/.local/bin" >> $GITHUB_PATH
+  ```
+
+  **Option 3: Start the runner interactively (development/testing only)**
+  Use `./run.sh` instead of the service to start the runner in an interactive
+  session that sources your shell profile. This is useful for debugging but
+  not suitable for production.
+
+  **Option 4: Change step shell to a login shell**
+  Override the shell at the step level to source the user profile:
+
+  ```yaml
+  - name: Run with login shell
+    shell: 'bash --login -e {0}'
+    run: my-tool --version
+  ```
+fix_code:
+  - language: yaml
+    label: 'Append user bin paths to runner PATH via .env file (persistent, affects all jobs)'
+    code: |
+      # Run this once on the self-hosted runner host:
+      # echo "PATH=/home/runner/.cargo/bin:/home/runner/.local/bin:$PATH" >> /home/runner/actions-runner/.env
+      # Then restart the runner service: sudo ./svc.sh stop && sudo ./svc.sh start
+      #
+      # In your workflow, the tool will now be found without any PATH workaround:
+      - name: Use cargo-installed tool
+        run: my-tool --version
+  - language: yaml
+    label: 'Append missing path per-job using $GITHUB_PATH'
+    code: |
+      jobs:
+        build:
+          runs-on: [self-hosted, linux]
+          steps:
+            - name: Add cargo bin to PATH
+              run: echo "$HOME/.cargo/bin" >> $GITHUB_PATH
+
+            - name: Use cargo-installed tool
+              run: my-tool --version  # Now visible because GITHUB_PATH was updated
+  - language: yaml
+    label: 'Use login shell on a single step to source ~/.profile'
+    code: |
+      - name: Run with login shell (sources ~/.profile and ~/.bash_profile)
+        shell: 'bash --login -e {0}'
+        run: |
+          my-tool --version
+prevention:
+  - 'After registering a self-hosted runner, verify PATH by running a debug step: `run: echo $PATH && which my-tool` to confirm expected binaries are visible.'
+  - 'Document all non-standard tool paths in your `.env` file at runner registration time, before registering as a service, so PATH is correct from the first job.'
+  - 'Prefer system-wide tool installations (e.g., `/usr/local/bin/`) over user-specific paths for tools used on self-hosted runners, so the service environment sees them without profile sourcing.'
+  - 'When using version managers like nvm, rbenv, pyenv, or asdf, their shims are typically installed into shell-profile-sourced directories and will NOT work in service-started runners without explicit PATH entries in `.env`.'
+docs:
+  - url: 'https://github.com/actions/runner/issues/2903'
+    label: 'actions/runner#2903 — Runner service does not update PATH when started via svc.sh'
+  - url: 'https://github.com/actions/runner/issues/2528'
+    label: 'actions/runner#2528 — PATH changes at runtime not applied to runner steps (--noprofile --norc)'
+  - url: 'https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners#adding-the-runner-to-your-enterprise'
+    label: 'GitHub Docs — Self-hosted runner environment configuration'
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#adding-a-system-path'
+    label: 'GitHub Docs — Adding a system path (GITHUB_PATH)'

package/errors/runner-environment/runner-environment-233.yml

@@ -0,0 +1,90 @@
+id: runner-environment-233
+title: 'actions/checkout < v6.0.3 fails on SHA-256 repositories — fatal: mismatched algorithms: client sha1; server sha256'
+category: runner-environment
+severity: error
+tags:
+  - checkout
+  - sha256
+  - git
+  - object-format
+  - hash-algorithm
+  - repository
+  - v6
+patterns:
+  - regex: 'fatal: mismatched algorithms: client sha1; server sha256'
+    flags: 'i'
+  - regex: 'fatal: mismatched algorithms: client sha256; server sha1'
+    flags: 'i'
+  - regex: 'mismatched algorithms.*sha1.*sha256'
+    flags: 'i'
+error_messages:
+  - 'fatal: mismatched algorithms: client sha1; server sha256'
+  - "The process '/usr/bin/git' failed with exit code 128"
+root_cause: |
+  GitHub is progressively rolling out support for SHA-256 object-format repositories
+  (also called NewHash or sha256-mode repos). When a repository is SHA-256-mode,
+  every git object reference is a 64-character hex SHA-256 hash instead of the
+  traditional 40-character SHA-1 hash.
+
+  Before actions/checkout v6.0.3, the checkout action always initialised the local
+  working-tree repository with a plain `git init`, which defaults to SHA-1 object
+  format. When the action then attempts to `git fetch` from a SHA-256 remote, git
+  detects that the local and remote repositories use different hash algorithms and
+  immediately aborts:
+
+    fatal: mismatched algorithms: client sha1; server sha256
+
+  The mismatch is unrecoverable — the local repository must be created with
+  `git init --object-format=sha256` BEFORE the first fetch. There is no in-place
+  conversion.
+
+  This only affects workflows where the target GitHub repository has been migrated
+  to or created as SHA-256 mode. GitHub began rolling out SHA-256 repository creation
+  in late 2025; adoption will grow over time. Previously-created SHA-1 repositories
+  are unaffected until they are explicitly migrated.
+
+  The fix shipped in actions/checkout v6.0.3 (June 2, 2026, commit 1cce339).
+  It calls the GitHub REST endpoint `GET /repos/{owner}/{repo}/hash-algorithm`
+  before `git init` and passes `--object-format=sha256` when the repository is
+  SHA-256 mode.
+
+  Source: actions/checkout#2160, PR#2439.
+fix: |
+  Upgrade to actions/checkout@v6.0.3 or later. Version v6.0.3 detects the
+  repository's object format via the GitHub API before initialising the local
+  git repository and passes the correct `--object-format` flag to `git init`.
+
+  If you cannot upgrade immediately, set the GIT_DEFAULT_HASH environment variable
+  to sha256 before running checkout, then reinitialise manually — but upgrading
+  the action is strongly preferred.
+
+  Note: v6.0.3 introduced a new REST API call (`GET /repos/.../hash-algorithm`) on
+  every checkout, which can cause secondary rate-limit issues for organisations with
+  very high parallel job counts. See runner-environment-206 for that separate issue.
+fix_code:
+  - language: yaml
+    label: 'Upgrade to actions/checkout v6.0.3+ to fix SHA-256 repository support'
+    code: |
+      - uses: actions/checkout@v6.0.3
+        with:
+          fetch-depth: 1
+  - language: yaml
+    label: 'Pin to v6.0.3+ by SHA for reproducibility (recommended for security-sensitive workflows)'
+    code: |
+      # Pin to the exact commit SHA of v6.0.3 to lock the version
+      - uses: actions/checkout@1cce3390c2bfda521930d01229c073c7ff920824  # v6.0.3
+        with:
+          fetch-depth: 1
+prevention:
+  - 'Always pin to a specific patch version of actions/checkout (e.g., @v6.0.3) rather than a floating major tag (@v6), so breaking changes from new GitHub repository features land on your own schedule'
+  - 'If your organisation creates new repositories, check whether SHA-256 mode is the default; SHA-256 repos will silently break all workflows using checkout < v6.0.3'
+  - 'Monitor the actions/checkout changelog when upgrading; v6.0.3 also introduced a new API call that can affect rate limits in high-parallelism environments (see runner-environment-206)'
+docs:
+  - url: 'https://github.com/actions/checkout/issues/2160'
+    label: 'actions/checkout#2160 — hashing mismatch error on SHA-256 repository'
+  - url: 'https://github.com/actions/checkout/pull/2439'
+    label: 'actions/checkout PR#2439 — Fix checkout init for SHA-256 repositories (merged June 2026)'
+  - url: 'https://github.com/actions/checkout/releases/tag/v6.0.3'
+    label: 'actions/checkout v6.0.3 release — SHA-256 repository support'
+  - url: 'https://git-scm.com/docs/hash-function-transition'
+    label: 'Git documentation — SHA-256 hash function transition'

package/errors/runner-environment/runner-environment-234.yml

@@ -0,0 +1,114 @@
+id: runner-environment-234
+title: "actions/checkout v6 credential helper overrides embedded PAT in cross-repo git push — 403 Permission denied to github-actions[bot]"
+category: runner-environment
+severity: error
+tags:
+  - checkout
+  - v6
+  - credential-helper
+  - cross-repo
+  - PAT
+  - git-push
+  - extraheader
+  - 403
+  - permission-denied
+patterns:
+  - regex: 'remote: Permission to .+\.git denied to github-actions\[bot\]'
+    flags: 'i'
+  - regex: 'fatal: unable to access .+github\.com.+: The requested URL returned error: 403'
+    flags: 'i'
+  - regex: 'Permission denied to github-actions\[bot\]\.'
+    flags: 'i'
+error_messages:
+  - 'remote: Permission to owner/nightly-releases.git denied to github-actions[bot].'
+  - 'fatal: unable to access ''https://github.com/owner/repo/'': The requested URL returned error: 403'
+root_cause: |
+  When a workflow uses actions/checkout v6 and then manually adds a second git remote
+  whose URL embeds a Personal Access Token (PAT), the cross-repo git push fails with
+  a 403 even though the PAT is valid and has the required scope.
+
+  actions/checkout injects a GitHub token (GITHUB_TOKEN by default) into the local
+  git configuration as an HTTP Authorization header for `https://github.com/` URLs
+  via `http.https://github.com/.extraheader`. A common pattern to push to a separate
+  repository using a PAT is to:
+    1. Add a remote with the PAT embedded in the URL:
+         git remote add nightly_repo https://TOKEN@github.com/owner/repo.git
+    2. Remove the checkout-injected extraheader to prevent it from conflicting:
+         git config --unset-all http.https://github.com/.extraheader
+    3. Push via the PAT URL remote.
+
+  This pattern worked correctly with actions/checkout v4 and v5. In v6, the sequence
+  fails because the action now also registers a git credential helper
+  (`credential.https://github.com.helper`) alongside the extraheader. When the
+  extraheader is manually unset in step 2, the credential helper remains configured.
+  Git consults the credential helper for all `https://github.com/` requests —
+  including the push to the PAT URL remote — and the helper returns GITHUB_TOKEN
+  (authenticated as `github-actions[bot]`). This token overrides the PAT embedded
+  in the remote URL, and since `github-actions[bot]` does not have write access to
+  the target repository, the push fails with HTTP 403.
+
+  The root distinction from earlier versions: unsetting `http.extraheader` alone is
+  no longer sufficient to fully remove checkout's credential injection in v6.
+
+  Source: actions/checkout#2424 (April 2026, open).
+fix: |
+  **Option 1 (recommended): Use `persist-credentials: false` in checkout.**
+  This prevents checkout from configuring any git credentials at all. The subsequent
+  git push uses the PAT embedded in the remote URL without interference.
+
+  **Option 2: Explicitly clear the credential helper after checkout.**
+  After the checkout step, unset both the extraheader AND the credential helper:
+    git config --unset-all http.https://github.com/.extraheader || true
+    git config --global --unset credential.https://github.com.helper || true
+    git config --global --unset credential.helper || true
+
+  Note: the exact helper key may vary; inspect `git config --list` to see all keys
+  set by checkout before unsetting.
+
+  **Option 3: Provide the PAT via the checkout `token:` input instead.**
+  If the PAT has access to both the primary repo and the target cross-repo, pass it
+  as the `token:` input so checkout configures it as the credential for all
+  github.com pushes. This avoids the need to inject a second credential entirely.
+fix_code:
+  - language: yaml
+    label: 'Recommended: use persist-credentials: false and embed PAT in remote URL'
+    code: |
+      - uses: actions/checkout@v6
+        with:
+          persist-credentials: false   # prevents checkout from injecting any git credentials
+
+      - name: Push tags to nightly releases repository
+        env:
+          NIGHTLY_PAT: ${{ secrets.NIGHTLY_PAT }}
+        run: |
+          git remote add nightly_repo \
+            "https://${NIGHTLY_PAT}@github.com/owner/nightly-releases.git"
+          git tag -f nightly
+          git push -f nightly_repo nightly
+  - language: yaml
+    label: 'Alternative: pass PAT to checkout token: input (when PAT has access to primary repo)'
+    code: |
+      - uses: actions/checkout@v6
+        with:
+          # If CROSS_REPO_PAT has access to the checked-out repo as well,
+          # checkout will configure it for all github.com credential requests.
+          token: ${{ secrets.CROSS_REPO_PAT }}
+
+      - name: Push tags to nightly releases repository
+        run: |
+          git remote add nightly_repo \
+            "https://${{ secrets.CROSS_REPO_PAT }}@github.com/owner/nightly-releases.git"
+          git tag -f nightly
+          git push -f nightly_repo nightly
+prevention:
+  - 'Use `persist-credentials: false` in any checkout step that is followed by a cross-repo git push using a PAT, to avoid checkout credential helpers interfering with the push'
+  - 'When debugging 403 errors on git push, check `git config --list` to see all credential-related configuration; look for any helper or extraheader keys referencing github.com'
+  - 'Avoid relying on unsetting only `http.https://github.com/.extraheader` to remove checkout credentials in v6+; the set of keys checkout writes has changed across versions'
+  - 'When migrating from actions/checkout v4/v5 to v6, test all workflows that manually manipulate git credentials or push to cross-repo remotes'
+docs:
+  - url: 'https://github.com/actions/checkout/issues/2424'
+    label: 'actions/checkout#2424 — Unable to create tags in another repo with v6 (403 Permission denied)'
+  - url: 'https://github.com/actions/checkout#usage'
+    label: 'actions/checkout README — persist-credentials input'
+  - url: 'https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication'
+    label: 'GitHub Docs — GITHUB_TOKEN automatic token authentication'