Intermittent cross-repository checkout identity mismatch: target origin points to the workflow repository #73023

We intermittently observe an external target checkout reporting the workflow-hosting repository as its origin, even though its checkout root, branch, and commit identify the intended target.

The behavior appears transient/intermittent. We do not have a reliable reproducer or a verified minimal reproduction. The configuration and command output below are sanitized examples of the observed workflow shape, not a deterministic reproduction.

The affected workflows run in an internal environment. We cannot share repository identities, run links, task payloads, or raw logs publicly.

Related context

• Support target-only checkout for MultiRepoOps #55797 introduced the target-only checkout use case for MultiRepoOps.
• Regression with target-only checkout failing with explicit GitHub App checkout #59470 reported a separate target-only checkout regression involving GitHub App token permissions.
• Target-only checkout documentation.

Both issues are closed. They provide context for the intended separation between the workflow repository and target repository; we are not claiming this is the same defect.

Environment

The inspected affected run used:

• GH-AW compiler/setup: v0.93.5
• GitHub Copilot CLI: 1.0.101
• AWF: v0.28.70
• GitHub Actions runner: 2.338.0
• GitHub-hosted Ubuntu 26.04
• Trigger: workflow_dispatch
• GitHub App authentication for the external target checkout

Representative configuration

The workflow repository supplies tooling, while a separate repository supplies content to edit. The implicit workspace-root checkout is also present.

permissions:
  contents: read
  copilot-requests: write

checkout:
  - path: tooling
    sparse-checkout: |
      .github/tools
      .github/schemas
  - repository: octo-org/content-repository
    ref: refs/heads/main
    path: target
    current: true
    github-app:
      client-id: ${{ vars.TARGET_APP_CLIENT_ID }}
      private-key: ${{ secrets.TARGET_APP_PRIVATE_KEY }}
      owner: octo-org
      repositories:
        - content-repository

Repository names, paths, and the base branch above are illustrative. This is an excerpt, not a complete reproducer. The inspected affected run did not use permissions.contents: none; whether target-only checkout avoids the behavior remains unverified.

Observed behavior

1. Checkout logs identify the intended external repository and requested branch, and record a target commit.

2. Before editing, the agent queries that checkout using an explicit absolute path:

   git -C "$GITHUB_WORKSPACE/target" rev-parse --show-toplevel
   git -C "$GITHUB_WORKSPACE/target" remote -v
   git -C "$GITHUB_WORKSPACE/target" rev-parse HEAD
   git -C "$GITHUB_WORKSPACE/target" branch --show-current
   git -C "$GITHUB_WORKSPACE/target" status --short

3. The root resolves to the intended target directory. HEAD matches the target commit recorded by checkout, the branch matches the requested branch, and the worktree is clean.

4. However, origin identifies the workflow-hosting repository instead of the content repository.

Sanitized example:

/workspace/target
origin  https://github.com/octo-org/automation-repository.git (fetch)
origin  https://github.com/octo-org/automation-repository.git (push)
<target-commit-recorded-by-checkout>
main

The agent had not edited files or changed remotes before this observation. In the inspected run, it treated the mismatch as a blocker, emitted report_incomplete, and created no PR. The workflow's result reporter classified the task as blocked.

Expected behavior

An explicit cross-repository checkout should retain its configured repository identity throughout setup, agent execution, and safe-output processing.

Credential setup may configure authentication, but should not change the remote to a different repository. If checkout identity cannot be established, execution should fail before editing or publication rather than rely on the agent to notice.

Investigation so far

• Replacing relative paths with absolute target paths did not eliminate the observed mismatch.
• The target root and content commit were correct when the wrong remote was reported. This does not look like simply running git in the wrong directory.
• We have not isolated the exact operation that changes the remote, quantified the frequency, or reproduced the behavior reliably in a minimal workflow.
• Successful PR creation should not be treated as evidence that checkout identity remained correct.

Possible credential-helper interaction — not a confirmed root cause

The generated workflow runs configure_git_credentials.sh in the current: true target directory and attempts to select its repository through step-level env.GITHUB_REPOSITORY.

The helper constructs an authenticated origin URL from GITHUB_REPOSITORY, GITHUB_SERVER_URL, and a token. However, GitHub documents GITHUB_* variables as reserved, and the Actions runner exports GitHub context values into script environments.

Could the helper therefore receive the workflow-hosting repository's identity despite the generated step declaring the target repository? This is a source-based hypothesis that fits the observed mismatch, not an experimentally confirmed explanation of the intermittent behavior.

Relevant public sources:

• Compiler credential-step generation, v0.93.5
• Credential helper, v0.93.5
• GitHub Actions default environment variables
• Runner script environment handling, v2.338.0

Requested investigation

• Confirm the supported checkout pattern for a central workflow repository editing an external target with GitHub App authentication.
• Check whether credential setup can replace a target remote with the workflow-hosting repository, including any reliance on overriding reserved variables.
• Consider validating repository identity before and after credential configuration, with credential-safe diagnostics that help locate any change.
• Add regression coverage for external checkouts marked current: true, including actual Actions environment-variable precedence.

We can collect additional sanitized diagnostics if maintainers identify which setup boundaries would be most useful to inspect.